9 ms·

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,...)

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 4y ago
More details: https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-...
niconii 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.
  - vmception 4y ago
    Browsers literally would not render with one tiny syntax error/spec-deviation in your HTML No different than having a JSX syntax error in React today
    - Macha 4y ago
      In XHTML strict mode, which basically nobody used. In XHTML transitional, and HTML1-4, what you'd get is browsers with divergent understandings of your DOM tree structure such that content that worked fine in one would be a horribly mangled mess (often breaking layout in difficult to read ways) in another browser.
      - wwweston 4y ago
        Some of us tried XHTML. A little bit of extra consistency in syntax and closed tags was rewarded with being able to use tooling built around XML expectations. I dug that. And then I found out there were some browsers that wouldn't handle it right unless content-type headers were set up right on the server, and of course that made it an extra pain, especially on commodity hosting where you might not have that remotely under your control. The "strict warnings"/"rendering problems crash the page" setting was also... mixed. Certainly prompted you to pinpoint the issue and fix it but that level of nag often felt unnecessarily militant after what everyone was used to.
irrational 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.

jefftk 4y ago

More details: https://html.spec.whatwg.org/multipage/syntax.html#optional-tags https://html.spec.whatwg.org/multipage/syntax.html#optional-...

niconii 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.
- vmception 4y ago
  Browsers literally would not render with one tiny syntax error/spec-deviation in your HTML No different than having a JSX syntax error in React today
  - Macha 4y ago
    In XHTML strict mode, which basically nobody used. In XHTML transitional, and HTML1-4, what you'd get is browsers with divergent understandings of your DOM tree structure such that content that worked fine in one would be a horribly mangled mess (often breaking layout in difficult to read ways) in another browser.
    - wwweston 4y ago
      Some of us tried XHTML. A little bit of extra consistency in syntax and closed tags was rewarded with being able to use tooling built around XML expectations. I dug that. And then I found out there were some browsers that wouldn't handle it right unless content-type headers were set up right on the server, and of course that made it an extra pain, especially on commodity hosting where you might not have that remotely under your control. The "strict warnings"/"rendering problems crash the page" setting was also... mixed. Certainly prompted you to pinpoint the issue and fix it but that level of nag often felt unnecessarily militant after what everyone was used to.

irrational 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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 4y 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.