Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write HTML Right

lofi.limo

Post reply on HN
Print view View original

151–160 of 212 posts

Re: Write HTML Right

#151

Post by zzo38computer »

movedx wrote: post #144

Author: write HTML right Me: this green on black background is terrible to read, I'll use reader mode Chrome: this author did not write their HTML correctly, so there is no reader mode available How ironic.

I use (a old version of) Firefox and can select "View > Page Style > No Style" to disable CSS, and this works OK for me (it is better than some web pages, where this does not work very good, but this one it works good).

I do not know what criteria are needed for the reader mode in Chrome. (The HTML code looks OK to me?)

Re: Write HTML Right

#152

Post by Voeid »

Figure 2. showing the "common style" is something I've never used or seen before.

What is the "right" way? Perhaps it is to use style from both of these extreme examples and write code that is easy to read and edit for the person that is working with it.

Or perhaps the right way is to never imply the way you are doing things is the only correct way and then try to pass it on as facts?

Re: Write HTML Right

#153

Post by exyi »

timw4mail wrote: post #80

No thanks. With the full markup you can see where things end, not just where they start. I think this is similar to semicolons in Javascript: with semicolons at the end of each statement there is no ambiguity, but if you do not have semicolons, you have to know about edge cases, like if a line starts with a square bracket or paren.

You can't disable this "feature", so you still don't know where things end / begin. Some tags can't be nested in

while you could expect that they can:

  

     Paragraph with a list won't work as you could think
       Test  
     Something else
Parses to:

  

    Paragraph with a list won't work as you could think
  

    Test  
  Something else
Similarly, in JS you are paying the price for optional semicolons even if you decide to use them.

   return
   {
      x: 1
   };
Will still not work even if you use semicolons elsewhere. So I don't see any advantage to actually using semicolons. JS is not worse than Python with it's basic inference, and yet in Python people will almost yell at you if you attempt to use a semicolon :)

I'd much prefer these features to be opt-in (yea, give me XHTML back for generated content). But when I can't can't disable them, why not embrace them ;)

Re: Write HTML Right

#154

Post by exyi »

buzzy_hacker wrote: post #64

> A few years ago, I found out I'd been tying my shoes wrong for my entire life. I thought laces came undone easily and didn't usually look very good. At least that's how mine were, and I never paid much attention to anyone else's. It took a couple of weeks to re-train my hands but now I have bows in my laces that look good and rarely come undone. I’m equally interested in this as the HTML. Any clue what the author i…

Not sure what he's referring to, I'm not familiar with the parallel posts. I just do the "rotate around the loop" part twice. I have had untied shoelace approximately twice in the last 5 years.

Re: Write HTML Right

#155

Post by exyi »

movedx wrote: post #144

Author: write HTML right Me: this green on black background is terrible to read, I'll use reader mode Chrome: this author did not write their HTML correctly, so there is no reader mode available How ironic.

Firefox's reader mode works just fine. You need a right browser for the right HTML.

... anyway, it bothers me sometimes that I'm not aware of any spec for "reader mode compatibility", did anyone see anything like that?

Re: Write HTML Right

#156

Post by gildas »

mst wrote: post #148
gildas wrote: post #128

Earlier quoted context omitted.

At first, I thought people would respect the issue template. In practice, very few do, even when a proper bug is reported. I completely agree with you but it seems to be a losing battle. So I just deal with these kinds of cases according to my mood. Concerning the bug #967, maybe I was not angry enough. Overall, the atmosphere on the bug tracker is fortunately very positive.

I think having one set of fairly clear and complete polite responses to the question to then be linked from elsewhere (or possibly turned into an FAQ ... and then linked to when people inevitably don't spot it in the FAQ before opening an issue ;) is probably a net win in terms of maintaining a positive atmosphere on your bug tracker.

It can help indeed! Thanks for the suggestion BTW [1]

[1] https://github.com/gildas-lormeau/SingleFile/commit/6c7a2ef1...

Re: Write HTML Right

#157

Post by exyi »

martin_a wrote: post #116

While I'm no big fan of SEO and all that surrounds it: Will this open-tag-thing here influence how crawlers handle your site and index/rank it?

I have no idea what Google does, but expect their parsers to be quite robust. I tried doing some web scraping, and so many pages are not even valid HTML (most often invalid nested tags, like a table inside span, missing closing tags even when required, random unopened closing tags, ...). Not closing

and tags is quite common, I have not seen omitted and yet.

Re: Write HTML Right

#158

Post by lelanthran »

mst wrote: post #146
timw4mail wrote: post #80

No thanks. With the full markup you can see where things end, not just where they start. I think this is similar to semicolons in Javascript: with semicolons at the end of each statement there is no ambiguity, but if you do not have semicolons, you have to know about edge cases, like if a line starts with a square bracket or paren.

I have a tendency to forget ASI in JS exists when I've only been looking at my own code rather than other people's for a while. I remain unconvinced it was a wise idea.

What is ASI?

Re: Write HTML Right

#159

Post by exyi »

jokoon wrote: post #89

I'm curious if a more strict html parser would actually be faster. Browsers are not really fast on my Android, and I wish they were fast.

I have yet to see a slow HTML-only website ;) (which is not 10MB single file spec or entire book). Really, I don't think html parsing is a huge bottleneck and these few parser exceptions don't seem to be that hard to implement - just close a tag if opening one of a predefined list, no backtracking or something expensive.

Re: Write HTML Right

#160

Post by giantrobot »

temporallobe wrote: post #18
egypturnash wrote: post #12

Earlier quoted context omitted.

…for non-tabular data such as “your pretty design elements that frame and organize the text because it is 1995 and CSS doesn’t exist yet and this is the only tool at your disposal for aligning stuff across the page”. Or because it is 2000 and putting stuff where you want it is a hell of CSS2 floats and box models and eventually you just say “fuck it” and assign table-like behavior to a bunch of divs because Tables Fo…

It’s funny you bring this up because while I have joined the Tables For Layout Are Considered Harmful club, I never really have heard a completely convincing argument on why tables have this bad rap. I think it’s mostly because, semantically, tables don’t make sense for layout, but back in the days before frameworks such as Foundation and Bootstrap (and more recently native CSS3 mechanisms), tables with invisible bor…

Tables don't lend to responsive layouts. If you've got a stereotypical layout with the middle row having a main content and sidebar column you can't really reflow that sidebar below the main content on mobile. With block elements (divs or semantic blocks) and CSS it's super simple to collapse multiple columns down to a single column for mobile. It's also simple to redo the same layout to handle super wide displays as well.

Tables for layout were fine back when everyone was browsing the web on SVGA, XGA, or even SXGA screens at 96dpi (72dpi on the Mac). Now a visitor might be on a high DPI display in portrait orientation, full screen on a 4K monitor, or anywhere in between I think it's a bit disrespectful to visitors not have have a responsive page layout. Tables are a liability for responsiveness and should only be used for tabular data.

Post reply on HN