6 ms·

Note that <html> and <body> auto-close and don't need to be terminated. Also, wrapping the <head> tags in an actual <head></head> is optional. You also don't

Note that <html> and <body> auto-close and don't need to be terminated. Also, wrapping the <head> tags in an actual <head></head> is optional. You also don't need the quotes as long the attribute doesn't have spaces or the like; <html lang=en> is OK. (kind of pointless as the average website fetches a bazillion bytes of javascript for every page load nowadays, but sometimes slimming things down as much as possible can be fun and satisfying)

chrismorgan 11mo ago
<html>, <head> and <body> start and end tags are all optional. In practice, you shouldn’t omit the <html> start tag because of the lang attribute, but the others never need any attributes. (If you’re putting attributes or classes on the body element, consider whether the html element is more appropriate.) It’s a long time since I wrote <head>, </head>, <body>, </body> or </html>.
zelphirkalt 11mo ago
This kind of thing will always just feel shoddy to me. It is not much work to properly close a tag. The number of bytes saved is negligible, compared to basically any other aspect of a website. Avoiding not needed div spam already would save more. Or for example making sure CSS is not bloated. And of course avoiding downloading 3MB of JS. What this achieves is making the syntax more irregular and harder to parse. I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient. It would greatly simplify browser code and HTML spec.
- ifwinterco 11mo ago
  You're not alone, this is called XHTML and it was tried but not enough people wanted to use it
  - sevenseacat 11mo ago
    oh man, I wish XHTML had won the war. But so many people (and CMSes) were creating dodgy markup that simply rendered yellow screens of doom, that no-one wanted it :(
    - adzm 11mo ago
      i'm glad it never caught on. the case sensitivity (especially for css), having to remember the xmlns namespace URI in the root element, CDATA sections for inline scripts, and insane ideas from companies about extending it further with more xml namespaced elements... it was madness.
      - imiric 11mo ago
        I'll copy what I wrote a few days ago: The fact XHTML didn't gain traction is a mistake we've been paying off for decades. Browser engines could've been simpler; web development tools could've been more robust and powerful much earlier; we would be able to rely on XSLT and invent other ways of processing and consuming web content; we would have proper XHTML modules, instead of the half-baked Web Components we have today. Etc. Instead, we got standards built on poorly specified conventions, and we still have to rely on 3rd-party frameworks to build anything beyond a toy web site. Stricter web documents wouldn't have fixed all our problems, but they would have certainly made a big impact for the better. And add: Yes, there were some initial usability quirks, but those could've been ironed out over time. Trading the potential of a strict markup standard for what we have today was a colossal mistake.
        recursive 11mo ago
        There's no way it could have gained traction. Consider two browsers. One follows the spec explicitly, and one goes into "best-effort" mode on encountering invalid markup. End users aren't going to care about the philosophical reasoning for why Browser A doesn't show them their school dance recital schedule. Consider JSON and CSV. Both have formal specs. But in the wild, most parsers are more lenient than the spec.
        ifwinterco 11mo ago
        Yeah this is it. We can debate what would be nicer theoretically until the cows come home but there's a kind of real world game theory that leads to browsers doing their best to parse all kinds of slop as well as they can, and then subsequently removing the incentive for developers and tooling to produce byte perfect output
  - zelphirkalt 11mo ago
    Yeah, I remember, when I was at school and first learning HTML and this kind of stuff. When I stumbled upon XHTML, I right away adapted my approach to verify my page as valid XHTML. Guess I was always on this side of things. Maybe machine empathy? Or also human empathy, because someone needs to write those parsers and the logic to process this stuff.
- Aransentin 11mo ago
  I agree for sure, but that's a problem with the spec, not the website. If there are multiple ways of doing something you might as well do the minimal one. The parser will have always to be able to handle all the edge cases no matter what anyway. You might want always consistently terminate all tags and such for aesthetic or human-centered (reduced cognitive load, easier scanning) reasons though, I'd accept that.
- bentley 11mo ago
  Implicit elements and end tags have been a part of HTML since the very beginning. They introduce zero ambiguity to the language, they’re very widely used, and any parser incapable of handling them violates the spec and would be incapable of handling piles of real‐world strict, standards‐compliant HTML. > I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient. They (W3C) tried that with XHTML. It was soundly rejected by webpage authors and by browser vendors. Nobody wants the Yellow Screen of Death. https://en.wikipedia.org/wiki/File:Yellow_screen_of_death.png https://en.wikipedia.org/wiki/File:Yellow_screen_of_death.pn...
  - haskellshill 11mo ago
    > They introduce zero ambiguity to the language Well, to parsing it for machines yes, but for humans writing and reading it they are helpful. For example, if you have <p> foo <p> bar and change it to <div> foo <div> bar suddenly you've got a syntax error (or some quirks mode rendering with nested divs). The "redundancy" of closing the tags acts basically like a checksum protecting against the "background radiation" of human editing. And if you're writing raw HTML without an editor that can autocomplete the closing tags then you're doing it wrong anyway. Yes that used to be common before and yes it's a useful backwards compatibility / newbie friendly feature for the language, but that doesn't mean you should use it if you know what you're doing.
    - recursive 11mo ago
      It sounds like you're headed towards XHTML. The rise and fall of XHTML is well documented and you can binge the whole thing if you're so inclined. But my summarization is that the reason it doesn't work is that strict document specs are too strict for humans. And at a time when there was legitimate browser competition, the one that made a "best effort" to render invalid content was the winner.
      - haskellshill 11mo ago
        The merits and drawbacks of XHTML has already been discussed elsewhere in the thread and I am well aware of it. > And at a time when there was legitimate browser competition, the one that made a "best effort" to render invalid content was the winner. Yes, my point is that there is no reason to still write "invalid" code just because it's supported for backwards compatibility reasons. It sounds like you ignored 90% of my comment, or perhaps you replied to the wrong guy?
- shiomiru 11mo ago
  > It would greatly simplify browser code and HTML spec. I doubt it would make a dent - e.g. in the "skipping <head>" case, you'd be replacing the error recovery mechanism of "jump to the next insertion mode" with "display an error", but a) you'd still need the code path to handle it, b) now you're in the business of producing good error messages which is notoriously difficult. Something that would actually make the parser a lot simpler is removing document.write, which has been obsolete ever since the introduction of the DOM and whose main remaining real world use-case seems to be ad delivery. (If it's not clear why this would help, consider that document.write can write scripts that call document.write, etc.)
- bazoom42 11mo ago
  > I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient. Who would want to use a browser which would prevent many currently valid pages from being shown?
  - zelphirkalt 11mo ago
    I mean, I am obviously talking about a fictive scenario, a somewhat better timeline/universe. In such a scenario, the shoddy practices of not properly closing tags and leaning on leniency in browser parsing and sophisticated fallbacks and all that would not have become a practice and those many currently valid websites would mostly not have been created, because as someone tried to create them, the browsers would have told them no. Then those people would revise their code, and end up with clean, easier to parse code/documents, and we wouldn't have all these edge and special cases in our standards. Also obviously that's unfortunately not the case today in our real world. Doesn't mean I cannot wish things were different.
nodesocket 11mo ago
Didn't know you can omit <head> .. </head> but I prefer for clarify to keep them.
- bentley 11mo ago
  Do you also spell out the implicit <tbody> in all your tables for clarity?
  - ndegruchy 11mo ago
    I do. `<thead>` and `<tfoot>`, too, if they're needed. I try to use all the free stuff that HTML gives you without needing to reach for JS. It's a surprising amount. Coupled with CSS and you can get pretty far without needing anything. Even just having `<template>` with minimal JS enables a ton of 'interactivity'.
  - christophilus 11mo ago
    Yes. Explicit is almost always better than implicit, in my experience.
  - tracker1 11mo ago
    Sometimes... especially if a single record displays across more than a single row. I almost always use thead.
alt187 11mo ago
I'm not sure I'd call keeping the <body> tag open satisfying but it is a fun fact.
tannhaeuser 11mo ago
Not only do html and body auto-close, their tags including start-element tags can be omitted alltogether: <title>Shortest valid doc</title> <p>Body text following here (cf explainer slides at [1] for the exact tag inferences SGML/HTML does to arrive at the fully tagged doc) [1]: https://sgmljs.sgml.net/docs/html5-dtd-slides-wrapper.html https://sgmljs.sgml.net/docs/html5-dtd-slides-wrapper.html (linked from https://sgmljs.sgml.net/blog/blog1701.html https://sgmljs.sgml.net/blog/blog1701.html)
qingcharles 11mo ago
> Note that <html> and <body> auto-close and don't need to be terminated. You monster.
busymom0 11mo ago
If I don't close something I opened, I feel weird.

chrismorgan 11mo ago

<html>, <head> and <body> start and end tags are all optional. In practice, you shouldn’t omit the <html> start tag because of the lang attribute, but the others never need any attributes. (If you’re putting attributes or classes on the body element, consider whether the html element is more appropriate.) It’s a long time since I wrote <head>, </head>, <body>, </body> or </html>.

zelphirkalt 11mo ago

This kind of thing will always just feel shoddy to me. It is not much work to properly close a tag. The number of bytes saved is negligible, compared to basically any other aspect of a website. Avoiding not needed div spam already would save more. Or for example making sure CSS is not bloated. And of course avoiding downloading 3MB of JS. What this achieves is making the syntax more irregular and harder to parse. I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient. It would greatly simplify browser code and HTML spec.

ifwinterco 11mo ago
You're not alone, this is called XHTML and it was tried but not enough people wanted to use it
- sevenseacat 11mo ago
  oh man, I wish XHTML had won the war. But so many people (and CMSes) were creating dodgy markup that simply rendered yellow screens of doom, that no-one wanted it :(
  - adzm 11mo ago
    i'm glad it never caught on. the case sensitivity (especially for css), having to remember the xmlns namespace URI in the root element, CDATA sections for inline scripts, and insane ideas from companies about extending it further with more xml namespaced elements... it was madness.
    - imiric 11mo ago
      I'll copy what I wrote a few days ago: The fact XHTML didn't gain traction is a mistake we've been paying off for decades. Browser engines could've been simpler; web development tools could've been more robust and powerful much earlier; we would be able to rely on XSLT and invent other ways of processing and consuming web content; we would have proper XHTML modules, instead of the half-baked Web Components we have today. Etc. Instead, we got standards built on poorly specified conventions, and we still have to rely on 3rd-party frameworks to build anything beyond a toy web site. Stricter web documents wouldn't have fixed all our problems, but they would have certainly made a big impact for the better. And add: Yes, there were some initial usability quirks, but those could've been ironed out over time. Trading the potential of a strict markup standard for what we have today was a colossal mistake.
      - recursive 11mo ago
        There's no way it could have gained traction. Consider two browsers. One follows the spec explicitly, and one goes into "best-effort" mode on encountering invalid markup. End users aren't going to care about the philosophical reasoning for why Browser A doesn't show them their school dance recital schedule. Consider JSON and CSV. Both have formal specs. But in the wild, most parsers are more lenient than the spec.
        ifwinterco 11mo ago
        Yeah this is it. We can debate what would be nicer theoretically until the cows come home but there's a kind of real world game theory that leads to browsers doing their best to parse all kinds of slop as well as they can, and then subsequently removing the incentive for developers and tooling to produce byte perfect output
- zelphirkalt 11mo ago
  Yeah, I remember, when I was at school and first learning HTML and this kind of stuff. When I stumbled upon XHTML, I right away adapted my approach to verify my page as valid XHTML. Guess I was always on this side of things. Maybe machine empathy? Or also human empathy, because someone needs to write those parsers and the logic to process this stuff.
Aransentin 11mo ago
I agree for sure, but that's a problem with the spec, not the website. If there are multiple ways of doing something you might as well do the minimal one. The parser will have always to be able to handle all the edge cases no matter what anyway. You might want always consistently terminate all tags and such for aesthetic or human-centered (reduced cognitive load, easier scanning) reasons though, I'd accept that.
bentley 11mo ago
Implicit elements and end tags have been a part of HTML since the very beginning. They introduce zero ambiguity to the language, they’re very widely used, and any parser incapable of handling them violates the spec and would be incapable of handling piles of real‐world strict, standards‐compliant HTML. > I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient. They (W3C) tried that with XHTML. It was soundly rejected by webpage authors and by browser vendors. Nobody wants the Yellow Screen of Death. https://en.wikipedia.org/wiki/File:Yellow_screen_of_death.png https://en.wikipedia.org/wiki/File:Yellow_screen_of_death.pn...
- haskellshill 11mo ago
  > They introduce zero ambiguity to the language Well, to parsing it for machines yes, but for humans writing and reading it they are helpful. For example, if you have <p> foo <p> bar and change it to <div> foo <div> bar suddenly you've got a syntax error (or some quirks mode rendering with nested divs). The "redundancy" of closing the tags acts basically like a checksum protecting against the "background radiation" of human editing. And if you're writing raw HTML without an editor that can autocomplete the closing tags then you're doing it wrong anyway. Yes that used to be common before and yes it's a useful backwards compatibility / newbie friendly feature for the language, but that doesn't mean you should use it if you know what you're doing.
  - recursive 11mo ago
    It sounds like you're headed towards XHTML. The rise and fall of XHTML is well documented and you can binge the whole thing if you're so inclined. But my summarization is that the reason it doesn't work is that strict document specs are too strict for humans. And at a time when there was legitimate browser competition, the one that made a "best effort" to render invalid content was the winner.
    - haskellshill 11mo ago
      The merits and drawbacks of XHTML has already been discussed elsewhere in the thread and I am well aware of it. > And at a time when there was legitimate browser competition, the one that made a "best effort" to render invalid content was the winner. Yes, my point is that there is no reason to still write "invalid" code just because it's supported for backwards compatibility reasons. It sounds like you ignored 90% of my comment, or perhaps you replied to the wrong guy?
shiomiru 11mo ago
> It would greatly simplify browser code and HTML spec. I doubt it would make a dent - e.g. in the "skipping <head>" case, you'd be replacing the error recovery mechanism of "jump to the next insertion mode" with "display an error", but a) you'd still need the code path to handle it, b) now you're in the business of producing good error messages which is notoriously difficult. Something that would actually make the parser a lot simpler is removing document.write, which has been obsolete ever since the introduction of the DOM and whose main remaining real world use-case seems to be ad delivery. (If it's not clear why this would help, consider that document.write can write scripts that call document.write, etc.)
bazoom42 11mo ago
> I wish all these tolerances wouldn't exist in HTML5 and browsers simply showed an error, instead of being lenient. Who would want to use a browser which would prevent many currently valid pages from being shown?
- zelphirkalt 11mo ago
  I mean, I am obviously talking about a fictive scenario, a somewhat better timeline/universe. In such a scenario, the shoddy practices of not properly closing tags and leaning on leniency in browser parsing and sophisticated fallbacks and all that would not have become a practice and those many currently valid websites would mostly not have been created, because as someone tried to create them, the browsers would have told them no. Then those people would revise their code, and end up with clean, easier to parse code/documents, and we wouldn't have all these edge and special cases in our standards. Also obviously that's unfortunately not the case today in our real world. Doesn't mean I cannot wish things were different.

nodesocket 11mo ago

Didn't know you can omit <head> .. </head> but I prefer for clarify to keep them.

bentley 11mo ago
Do you also spell out the implicit <tbody> in all your tables for clarity?
- ndegruchy 11mo ago
  I do. `<thead>` and `<tfoot>`, too, if they're needed. I try to use all the free stuff that HTML gives you without needing to reach for JS. It's a surprising amount. Coupled with CSS and you can get pretty far without needing anything. Even just having `<template>` with minimal JS enables a ton of 'interactivity'.
- christophilus 11mo ago
  Yes. Explicit is almost always better than implicit, in my experience.
- tracker1 11mo ago
  Sometimes... especially if a single record displays across more than a single row. I almost always use thead.

alt187 11mo ago

I'm not sure I'd call keeping the <body> tag open satisfying but it is a fun fact.

tannhaeuser 11mo ago

Not only do html and body auto-close, their tags including start-element tags can be omitted alltogether: <title>Shortest valid doc</title> <p>Body text following here (cf explainer slides at [1] for the exact tag inferences SGML/HTML does to arrive at the fully tagged doc) [1]: https://sgmljs.sgml.net/docs/html5-dtd-slides-wrapper.html https://sgmljs.sgml.net/docs/html5-dtd-slides-wrapper.html (linked from https://sgmljs.sgml.net/blog/blog1701.html https://sgmljs.sgml.net/blog/blog1701.html)

qingcharles 11mo ago

> Note that <html> and <body> auto-close and don't need to be terminated. You monster.

busymom0 11mo ago

If I don't close something I opened, I feel weird.