4 ms·

Guess what, you're not required to open <html>, <head>, or <body> either. It all follows from SGML tag inference rules, and the rules aren't that difficult to u

Guess what, you're not required to open <html>, <head>, or <body> either. It all follows from SGML tag inference rules, and the rules aren't that difficult to understand. What makes them appear magical is WHATWG's verbose ad-hoc parsing algorithm presentation explicitly listing eg. elements that close their parents originally captured from SGML but having become unmaintained as new elements were added. This already started to happen in the very first revision after Ian Hickson's initial procedural HTML parsing description ([1]). I'd also wish people would stop calling every element-specific behavior HTML parsers do "liberal and tag-soup"-like. Yes WHATWG HTML does define error recovery rules, and HTML had introduced historic blunders to accomodate inline CSS and inline JS, but almost always what's being complained about are just SGML empty elements (aka HTML void elements) or tag omission (as described above) by folks not doing their homework. [1]: https://sgmljs.sgml.net/docs/html5.html#tag-omission https://sgmljs.sgml.net/docs/html5.html#tag-omission (see also XML Prague 2017 proceedings pp. 101ff)

pwdisswordfishy 9mo ago
This is what I complain about: https://nvd.nist.gov/vuln/detail/CVE-2020-26870 https://nvd.nist.gov/vuln/detail/CVE-2020-26870 https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not-to-break-a-site/ https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not... https://bughunters.google.com/blog/5038742869770240/escaping-and-in-attributes-how-it-helps-protect-against-mutation-xss https://bughunters.google.com/blog/5038742869770240/escaping... None of those problems exist in XHTML.
- tannhaeuser 9mo ago
  I guess you're replying to my comment because you were triggered by my last sentence. I wasn't criticizing you specifically, but yeah, in another comment you're writing > It probably didn't help that XHTML did not offer any new features over tag-soup HTML syntax. which unfortunately reaks of exactly the kind of roundabout HTML criticism that is not so helpful IMO. We have to face the possibility that most HTML documents have already been written at this point, at least if you value text by humans. The CVEs you're referencing are due to said historic blunders allowing inline JS or otherwise tunneling foreign syntax in markup constructs (mutation XSSs are only triggered by serialising and reparsing HTML as part of bogus sanitizer libs anyway). If you look at past comments of mine, you'll notice I'm staunchly criticizing inline JS and CSS (should always be placed in external "resources") and go as far as saying CSS or other ad-hoc item-value syntax should not even exist when attributes already serve this purpose. The remaining CVE is made possible by Hickson's overly liberal rules for what's allowed or needs escaping in attributes vs SGML's much stricter rules.
  - modeless 9mo ago
    Inline JS or CSS is fine if typed directly by humans. It's only a problem when generated. Generated resources should always be in separate files. I like the flexibility of being able to make one file HTML apps with inline resources when I'm not generating code. But there should be better protections against including inline scripts in generated code unintentionally.
modeless 9mo ago
HTML becomes pretty delightful for prototyping when you embrace this. You can open up an empy file and start typing tags with zero boilerplate. Drop in a script tag and forget about getElementById(); every id attribute already defines a JavaScript variable name directly, so go to town. Today the specs guarantee consistent behavior so this doesn't introduce compatiblity issues like it did in the bad old days of IE6. You can make surprisingly powerful stuff in a single file application with no fluff. I just wish browsers weren't so anal about making you load things from http://localhost instead of file:// directly. Someone ought to look into fixing the security issues of file:// URLs so browsers can relax about that.
- circuit10 9mo ago
  Wow, I had never heard of that ID -> variable feature
  - modeless 9mo ago
    Yeah it was hard to believe when I first learned about it, but it's true. I think I first found out when I forgot to put in a getElementById call and my code still worked.
  - BiteCode_dev 9mo ago
    Also window.document.forms gets you direct access to all forms, "name" automatically attach an attribute to the parents and "this" rebind to the current element on inline event handler. The DOM API may have been very messy at creation, but it is also very handy and powerful, especially for binding to a live programming visual environment with instant remote update capabilities.
    - halapro 9mo ago
      Speaking of forms: form.elements.username is my preferred way of accessing form fields. You can also use a field .form prop to access its connected form. This is fundamental when the field exists outside <form> ;)
skobes 9mo ago
Omitting <body> can lead to weird surprises. I once had some JavaScript mysteriously breaking because document.body was null during inline execution. Since then I always write <body> explicitly even though it is optional.

pwdisswordfishy 9mo ago

This is what I complain about: https://nvd.nist.gov/vuln/detail/CVE-2020-26870 https://nvd.nist.gov/vuln/detail/CVE-2020-26870 https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not-to-break-a-site/ https://sirre.al/2025/08/06/safe-json-in-script-tags-how-not... https://bughunters.google.com/blog/5038742869770240/escaping-and-in-attributes-how-it-helps-protect-against-mutation-xss https://bughunters.google.com/blog/5038742869770240/escaping... None of those problems exist in XHTML.

tannhaeuser 9mo ago
I guess you're replying to my comment because you were triggered by my last sentence. I wasn't criticizing you specifically, but yeah, in another comment you're writing > It probably didn't help that XHTML did not offer any new features over tag-soup HTML syntax. which unfortunately reaks of exactly the kind of roundabout HTML criticism that is not so helpful IMO. We have to face the possibility that most HTML documents have already been written at this point, at least if you value text by humans. The CVEs you're referencing are due to said historic blunders allowing inline JS or otherwise tunneling foreign syntax in markup constructs (mutation XSSs are only triggered by serialising and reparsing HTML as part of bogus sanitizer libs anyway). If you look at past comments of mine, you'll notice I'm staunchly criticizing inline JS and CSS (should always be placed in external "resources") and go as far as saying CSS or other ad-hoc item-value syntax should not even exist when attributes already serve this purpose. The remaining CVE is made possible by Hickson's overly liberal rules for what's allowed or needs escaping in attributes vs SGML's much stricter rules.
- modeless 9mo ago
  Inline JS or CSS is fine if typed directly by humans. It's only a problem when generated. Generated resources should always be in separate files. I like the flexibility of being able to make one file HTML apps with inline resources when I'm not generating code. But there should be better protections against including inline scripts in generated code unintentionally.

modeless 9mo ago

HTML becomes pretty delightful for prototyping when you embrace this. You can open up an empy file and start typing tags with zero boilerplate. Drop in a script tag and forget about getElementById(); every id attribute already defines a JavaScript variable name directly, so go to town. Today the specs guarantee consistent behavior so this doesn't introduce compatiblity issues like it did in the bad old days of IE6. You can make surprisingly powerful stuff in a single file application with no fluff. I just wish browsers weren't so anal about making you load things from http://localhost instead of file:// directly. Someone ought to look into fixing the security issues of file:// URLs so browsers can relax about that.

circuit10 9mo ago
Wow, I had never heard of that ID -> variable feature
- modeless 9mo ago
  Yeah it was hard to believe when I first learned about it, but it's true. I think I first found out when I forgot to put in a getElementById call and my code still worked.
- BiteCode_dev 9mo ago
  Also window.document.forms gets you direct access to all forms, "name" automatically attach an attribute to the parents and "this" rebind to the current element on inline event handler. The DOM API may have been very messy at creation, but it is also very handy and powerful, especially for binding to a live programming visual environment with instant remote update capabilities.
  - halapro 9mo ago
    Speaking of forms: form.elements.username is my preferred way of accessing form fields. You can also use a field .form prop to access its connected form. This is fundamental when the field exists outside <form> ;)

skobes 9mo ago

Omitting <body> can lead to weird surprises. I once had some JavaScript mysteriously breaking because document.body was null during inline execution. Since then I always write <body> explicitly even though it is optional.