5 ms·

HTML as an authoring language is underrated, but several commenters are confusing "writing HTML" with the aesthetic of nearly unstyled HTML. I think this is ha

by jefftk 5y ago

HTML as an authoring language is underrated, but several commenters are confusing "writing HTML" with the aesthetic of nearly unstyled HTML. I think this is happening because the post we're discussing is not itself an example of what the author is describing: it's authored in DWikiText. An example (that I maintain) of what the author describes: https://www.bidadance.org https://www.bidadance.org. Each of the pages is just plain HTML on disk.

thunderbong 5y ago
Why aren't any of the paragraph tags closed?
- enriquto 5y ago
  Because it's unnecessary in html5, just like closing li, td, tr tags. When you use implicit tags (body, header, etc) and auto-closing tags (li, p, tr, td,...) then html becomes refreshingly lean and human-editable. EDIT: for a nice summary, look at google's html style guide. Section 3.1.7 is particularly neat [0]. [0] https://google.github.io/styleguide/htmlcssguide.html#Optional_Tags https://google.github.io/styleguide/htmlcssguide.html#Option...
  - jefftk 5y ago
    More details: https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-...
  - niconii 5y ago
    Just to clarify, HTML5 didn't introduce this, it's been the case since at least 1993. https://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html https://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
    - jefftk 5y ago
      Before HTML5 it was common to hear things like "technically you don't need it, but it's not to spec so don't do it".
      - zerocrates 5y ago
        Probably mostly a casualty of that window when people were trying to make XHTML happen, so all the SGML-isms like omitted close tags became verboten.
      - niconii 5y ago
        Well, then they were wrong, because it's always been part of every HTML spec. Perhaps they were thinking of XHTML, which did require all tags because it was based on XML.
        nicoburns 5y ago
        I believe before html5 they weren't required, but what the parsed DOM tree looked like wasn't clearly defined if they weren't, and in practice different browsers did it differently meaning you could very easily end up with it rendering differently in different browsers. html5 fixed that.
        niconii 5y ago
        Oh, for sure, actually parsing HTML was awful before HTML5. The spec sometimes diverged from how browsers actually interpreted HTML, and error correction basically boiled down to browsers trying to reverse-engineer each other to figure out how they handled broken HTML. HTML5 was a godsend for actually standardizing all of that.
        anjbe 5y ago
        This is not correct. What you’re describing sounds like how HTML5 standardized parsing of invalid HTML, but that is not the same thing as implicit closing tags, which have have always been valid, correct HTML producing an unambiguous, clearly defined result.
      - 5y ago
  - irrational 5y ago
    I don’t understand how they are optional. <p>Qed. <img src=“some_image.jpg”> And <p>Qed.</p> <img src=“some_image.jpg”> Are going to give me different results.
    - jefftk 5y ago
      It's are "optional" in the sense that the spec says it's optional and defines what that means: "A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element."
      - irrational 5y ago
        LOL. So I can memorize or check that list every time I'm using a p tag (and, of course, I'm relying on someone not doing something like changing the display property of a block element to inline), or... I can just use a closing p tag. I know which one is infinitely easier for me.
        jefftk 5y ago
        You can memorize the list, but it's easier than that: things that can go in a paragraph (which includes images) let the <p> continue, while things that can't (which is the long list there) close the <p>. In practice you get used to it very quickly.
        niconii 5y ago
        I mentioned "block elements" in my other comment, but to be clear, CSS has no effect on how HTML is parsed, so the display property isn't relevant here. Furthermore, you need to know about this rule even if you do write `</p>`. If you write this: <p> <div>hello</div> </p> it is invalid HTML. This is because the paragraph is auto-closed, and then your code is equivalent to this: <p> </p><div>hello</div> </p> resulting in an error because of the extra `</p>` after the `</div>`.
  - niconii 5y ago
    Okay, I've gotten a bit carried away with HTML spec minutia elsewhere in these comments, mainly because this stuff really isn't common knowledge among web developers and it's hard to resist talking about it. However, I also want to add to the other point here; namely, "why do this in the first place?" Google mentions "file size optimization" in the style guide linked above, and it led to criticism on HN and elsewhere along the lines of "sure, maybe shaving off a few bytes adds up for Google, but you're not Google." However, this really isn't why I do it, and I think maybe it's poisoned the discussion a bit. For me, it's mostly about reducing visual noise. It's not necessarily less typing if you're using an editor that auto-inserts closing tags, but I think it's harder to read with the end tags, particularly when it comes to tables. For instance, consider this table (which, if you're curious, is about Super Nintendo audio samples): <table> <tr><th>sample rate</th> <th>data rate</th> <th>max length</th></tr> <tr><td>32000 Hz</td> <td>18000 byte/s</td> <td> ~3.641 s</td></tr> <tr><td>16000 Hz</td> <td> 9000 byte/s</td> <td> ~7.282 s</td></tr> <tr><td> 8000 Hz</td> <td> 4500 byte/s</td> <td>~14.564 s</td></tr> </table> And now, take a look at it without the optional end tags: <table> <tr><th>sample rate <th>data rate <th>max length <tr><td>32000 Hz <td>18000 byte/s <td> ~3.641 s <tr><td>16000 Hz <td> 9000 byte/s <td> ~7.282 s <tr><td> 8000 Hz <td> 4500 byte/s <td>~14.564 s </table> Personally, this is much easier for me to read and maintain. There's also much less chance of me accidentally mismatching opening and closing tags, since I've eliminated almost all of the closing tags besides </table>. On top of that, let's be honest, <html><head></head><body></body></html> is just useless boilerplate. We all know what goes in the head and what goes in the body, and I think we can all figure out where the HTML starts and ends. The browser knows all of this too, which is why all of those tags are completely optional. Not only does getting rid of that make the code less noisy, it solves the age-old problem of "should I indent the head and body or not?" (Though, in practice, I still keep <html lang=en> so that I can specify the language for people who use screen readers. </html> is just silly, though.)
    - rchaud 5y ago
      How likely is it that a dev would be reading an HTML table with hardcoded data in the code editor in this day and age? Today, data tables are mostly dynamically generated, probably via accessing an API endpoint of some sort. The dev would at most write a function that would output the data inside a <table> element. But the table data itself would only be visible in the browser, it wouldn't be hardcoded into the HTML markup.
cmroanirgo 5y ago
Looking at the article's source and then yours, I see no correlation. The author is clearly talking about authoring in html without any tooling, whereas yours clearly has a tooled event list. It's not an article taking about whether external files are used. In fact, the article talks how they style it to match their wiki, & that the article is not authored in DWikiText at all. Edit: you cheated by changing uri. The point still stands for your home page
- jefftk 5y ago
  Sorry, I put the URL back to the root of the site. (I'd changed it to a page that I thought better illustrated this approach.) The events list is created with JS, yes. But that's the only thing on the whole site (~25 pages) that works that way. Here's another site I maintain this way where the events list is plain HTML: https://www.kingfisherband.com https://www.kingfisherband.com
tedunangst 5y ago
It's not like the post is unclear that it's talking about a site other than itself. People just can't read good.
deleted 5y ago
[deleted]

by jefftk 5y ago

thunderbong 5y ago

Why aren't any of the paragraph tags closed?

enriquto 5y ago
Because it's unnecessary in html5, just like closing li, td, tr tags. When you use implicit tags (body, header, etc) and auto-closing tags (li, p, tr, td,...) then html becomes refreshingly lean and human-editable. EDIT: for a nice summary, look at google's html style guide. Section 3.1.7 is particularly neat [0]. [0] https://google.github.io/styleguide/htmlcssguide.html#Optional_Tags https://google.github.io/styleguide/htmlcssguide.html#Option...
- jefftk 5y ago
  More details: https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-...
- niconii 5y ago
  Just to clarify, HTML5 didn't introduce this, it's been the case since at least 1993. https://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html https://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
  - jefftk 5y ago
    Before HTML5 it was common to hear things like "technically you don't need it, but it's not to spec so don't do it".
    - zerocrates 5y ago
      Probably mostly a casualty of that window when people were trying to make XHTML happen, so all the SGML-isms like omitted close tags became verboten.
    - niconii 5y ago
      Well, then they were wrong, because it's always been part of every HTML spec. Perhaps they were thinking of XHTML, which did require all tags because it was based on XML.
      - nicoburns 5y ago
        I believe before html5 they weren't required, but what the parsed DOM tree looked like wasn't clearly defined if they weren't, and in practice different browsers did it differently meaning you could very easily end up with it rendering differently in different browsers. html5 fixed that.
        niconii 5y ago
        Oh, for sure, actually parsing HTML was awful before HTML5. The spec sometimes diverged from how browsers actually interpreted HTML, and error correction basically boiled down to browsers trying to reverse-engineer each other to figure out how they handled broken HTML. HTML5 was a godsend for actually standardizing all of that.
        anjbe 5y ago
        This is not correct. What you’re describing sounds like how HTML5 standardized parsing of invalid HTML, but that is not the same thing as implicit closing tags, which have have always been valid, correct HTML producing an unambiguous, clearly defined result.
    - 5y ago
- irrational 5y ago
  I don’t understand how they are optional. <p>Qed. <img src=“some_image.jpg”> And <p>Qed.</p> <img src=“some_image.jpg”> Are going to give me different results.
  - jefftk 5y ago
    It's are "optional" in the sense that the spec says it's optional and defines what that means: "A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element."
    - irrational 5y ago
      LOL. So I can memorize or check that list every time I'm using a p tag (and, of course, I'm relying on someone not doing something like changing the display property of a block element to inline), or... I can just use a closing p tag. I know which one is infinitely easier for me.
      - jefftk 5y ago
        You can memorize the list, but it's easier than that: things that can go in a paragraph (which includes images) let the <p> continue, while things that can't (which is the long list there) close the <p>. In practice you get used to it very quickly.
      - niconii 5y ago
        I mentioned "block elements" in my other comment, but to be clear, CSS has no effect on how HTML is parsed, so the display property isn't relevant here. Furthermore, you need to know about this rule even if you do write `</p>`. If you write this: <p> <div>hello</div> </p> it is invalid HTML. This is because the paragraph is auto-closed, and then your code is equivalent to this: <p> </p><div>hello</div> </p> resulting in an error because of the extra `</p>` after the `</div>`.
- niconii 5y ago
  Okay, I've gotten a bit carried away with HTML spec minutia elsewhere in these comments, mainly because this stuff really isn't common knowledge among web developers and it's hard to resist talking about it. However, I also want to add to the other point here; namely, "why do this in the first place?" Google mentions "file size optimization" in the style guide linked above, and it led to criticism on HN and elsewhere along the lines of "sure, maybe shaving off a few bytes adds up for Google, but you're not Google." However, this really isn't why I do it, and I think maybe it's poisoned the discussion a bit. For me, it's mostly about reducing visual noise. It's not necessarily less typing if you're using an editor that auto-inserts closing tags, but I think it's harder to read with the end tags, particularly when it comes to tables. For instance, consider this table (which, if you're curious, is about Super Nintendo audio samples): <table> <tr><th>sample rate</th> <th>data rate</th> <th>max length</th></tr> <tr><td>32000 Hz</td> <td>18000 byte/s</td> <td> ~3.641 s</td></tr> <tr><td>16000 Hz</td> <td> 9000 byte/s</td> <td> ~7.282 s</td></tr> <tr><td> 8000 Hz</td> <td> 4500 byte/s</td> <td>~14.564 s</td></tr> </table> And now, take a look at it without the optional end tags: <table> <tr><th>sample rate <th>data rate <th>max length <tr><td>32000 Hz <td>18000 byte/s <td> ~3.641 s <tr><td>16000 Hz <td> 9000 byte/s <td> ~7.282 s <tr><td> 8000 Hz <td> 4500 byte/s <td>~14.564 s </table> Personally, this is much easier for me to read and maintain. There's also much less chance of me accidentally mismatching opening and closing tags, since I've eliminated almost all of the closing tags besides </table>. On top of that, let's be honest, <html><head></head><body></body></html> is just useless boilerplate. We all know what goes in the head and what goes in the body, and I think we can all figure out where the HTML starts and ends. The browser knows all of this too, which is why all of those tags are completely optional. Not only does getting rid of that make the code less noisy, it solves the age-old problem of "should I indent the head and body or not?" (Though, in practice, I still keep <html lang=en> so that I can specify the language for people who use screen readers. </html> is just silly, though.)
  - rchaud 5y ago
    How likely is it that a dev would be reading an HTML table with hardcoded data in the code editor in this day and age? Today, data tables are mostly dynamically generated, probably via accessing an API endpoint of some sort. The dev would at most write a function that would output the data inside a <table> element. But the table data itself would only be visible in the browser, it wouldn't be hardcoded into the HTML markup.

cmroanirgo 5y ago

Looking at the article's source and then yours, I see no correlation. The author is clearly talking about authoring in html without any tooling, whereas yours clearly has a tooled event list. It's not an article taking about whether external files are used. In fact, the article talks how they style it to match their wiki, & that the article is not authored in DWikiText at all. Edit: you cheated by changing uri. The point still stands for your home page

jefftk 5y ago
Sorry, I put the URL back to the root of the site. (I'd changed it to a page that I thought better illustrated this approach.) The events list is created with JS, yes. But that's the only thing on the whole site (~25 pages) that works that way. Here's another site I maintain this way where the events list is plain HTML: https://www.kingfisherband.com https://www.kingfisherband.com

tedunangst 5y ago

It's not like the post is unclear that it's talking about a site other than itself. People just can't read good.

deleted 5y ago

[deleted]