5 ms·

The time where I had to worry about the HTML parser is mostly gone, though I don't know if it is because the situation got better with HTML5 or if I am just use

The time where I had to worry about the HTML parser is mostly gone, though I don't know if it is because the situation got better with HTML5 or if I am just used to all the warts. The thing I dislike most is the treatment of self-closing tags like <br />. In HTML5, the correct form is <br> but you can add the slash and it is ignored as syntactic sugar. But you cannot write <div id="mydiv" />. In XHTML, this was a shorthand for <div id="mydiv"></div>. It's really ugly that you have to write the closing tag in this case, and for seemingly no reason. https://stackoverflow.com/questions/3558119/are-non-void-self-closing-tags-valid-in-html5 https://stackoverflow.com/questions/3558119/are-non-void-sel...

masklinn 5y ago
> But you cannot write <div id="mydiv" />. Sure you can. And exactly as with <br/> the / is ignored. Ignored means exactly that. HTML does not have xml-style self-closing tags at all. > for seemingly no reason. The reason is pretty simple: there were no self/closing tags in SGML, so there were no self-closing tags in the mangled mess browsers made of it. The goal of the HTML5 parser effort was to create an interoperable and backwards compatible parsing algorithm. Adding self-closing tags to the langage would have tin counter to that goal and would definitely have broken existing code unnecessarily, even though it might have been convenient in some cases.
- deleted 5y ago
  [deleted]
- saurik 5y ago
  >> But you cannot write <div id="mydiv" />. > Sure you can. And exactly as with <br/> the / is ignored. Obviously, the phrase "you cannot write" has the context "as a shorthand for self-closing the tag", and doesn't deserve some pedantic "of course you can do that, it just doesn't do what you hoped it would" response :/. To really be pedantic about it: SGML actually had a feature similar to this feature and HTML specified it; however, the syntax "<br/" was a valid way to write that tag (technically an open tag, but due to the DTD it would auto close) and the ">" after would get rendered... not ignored (and in fact might even cause the document to fail if that > was in a disallowed context of a strict document). https://jkorpela.fi/html/empty.html https://jkorpela.fi/html/empty.html Ironically, the W3's comment on this is to discourage its usage "until widely deployed", as they have essentially always specified stuff no one implemented correctly (lol). https://www.w3.org/MarkUp/html3/HTMLandSGML.html https://www.w3.org/MarkUp/html3/HTMLandSGML.html
- El_RIDO 5y ago
  My workaround for this is to write XHTML 5. Now, that standard AFAIK never materialized, but modern browsers will still happily use their XML parser if you serve the document as application/xhtml+xml instead of their default (slower) tag-soup parser to create a DOM-tree out of it and after that their HTML 5 support ensures that they render it correctly. If and when browsers drop their XML parser, I hope they will just parse these docs as HTML and only then would I loose the option of self-closing tags.
  - LinAGKar 5y ago
    It didn't "never materialize". It's part of the HTML5 spec (although it's not called XHTML anymore, it's just HTML5 with XML syntax): https://html.spec.whatwg.org/#the-xhtml-syntax https://html.spec.whatwg.org/#the-xhtml-syntax
- captainmuon 5y ago
  > Ignored means exactly that. HTML does not have xml-style self-closing tags at all. You are answering my complaint by repeating the fact that I complained about? :-D > The goal of the HTML5 parser effort was to create an interoperable and backwards compatible parsing algorithm. Adding self-closing tags to the langage would have tin counter to that goal and would definitely have broken existing code unnecessarily, even though it might have been convenient in some cases. I'd wager that in pre-HTML5 code, the overwhelming amount of cases of <div /> were supposed to mean <div></div> and not <div>.... Why would you even put the slash there if you wanted an opening tag? HTML5 would have been a great opportunity to legalize the former behavior, and that would have broken less code. I distinctivly remember that the self-closing worked as expected even on non-void-tags in quirks mode (not XTML) in the mid 2000s, because at some point I had to fix them after new browser versions came out.
bambax 5y ago
Unpopular opinion: I like XML, and I liked self-closing tags as well. It made more sense. The problem with being lax in what you accept is that it builds immense complexity because you have to deal with a potentially infinite number of special cases. But this books appears excellent. I read the encoding chapter just now, and it was very engaging and informative, explaining the historical reasons why things are the way they are. For example, it says that meta tag about character encoding were initially meant to be read by the server so that it could set the proper encoding header... Which they never did... I did not know that!
- heavenlyblue 5y ago
  How can a server read a tag if it doesn’t know which encoding to interpret the tag in the first place?
  - bambax 5y ago
    I'm guessing, like the HTML parser does: by doing a "pre-parse". The pre-parser is yet another HTML parser, specialized on this task. This is well described in the book and this is how browsers do it today. It seems no web server ever implemented it; it would probably have been a little beneficial because each file would only need to be pre-parsed when it is written on disk (or first read by the server), instead of this being done by every client on every load. It makes me think, maybe other kinds of analysis and normalization could be done by the server, which would allow for simpler (and stricter) browsers.
- IshKebab 5y ago
  I'm not following what your unpopular opinion is. I think everyone would have preferred it if XHTML had been a success.
LinAGKar 5y ago
HTML5 does have have a strict specification for how it is parsed, unlike previous versions. Also, you can still write HTML5 as XML (XHTML5). It's not talked about much, but it's totally a thing.

masklinn 5y ago

> But you cannot write <div id="mydiv" />. Sure you can. And exactly as with <br/> the / is ignored. Ignored means exactly that. HTML does not have xml-style self-closing tags at all. > for seemingly no reason. The reason is pretty simple: there were no self/closing tags in SGML, so there were no self-closing tags in the mangled mess browsers made of it. The goal of the HTML5 parser effort was to create an interoperable and backwards compatible parsing algorithm. Adding self-closing tags to the langage would have tin counter to that goal and would definitely have broken existing code unnecessarily, even though it might have been convenient in some cases.

deleted 5y ago
[deleted]
saurik 5y ago
>> But you cannot write <div id="mydiv" />. > Sure you can. And exactly as with <br/> the / is ignored. Obviously, the phrase "you cannot write" has the context "as a shorthand for self-closing the tag", and doesn't deserve some pedantic "of course you can do that, it just doesn't do what you hoped it would" response :/. To really be pedantic about it: SGML actually had a feature similar to this feature and HTML specified it; however, the syntax "<br/" was a valid way to write that tag (technically an open tag, but due to the DTD it would auto close) and the ">" after would get rendered... not ignored (and in fact might even cause the document to fail if that > was in a disallowed context of a strict document). https://jkorpela.fi/html/empty.html https://jkorpela.fi/html/empty.html Ironically, the W3's comment on this is to discourage its usage "until widely deployed", as they have essentially always specified stuff no one implemented correctly (lol). https://www.w3.org/MarkUp/html3/HTMLandSGML.html https://www.w3.org/MarkUp/html3/HTMLandSGML.html
El_RIDO 5y ago
My workaround for this is to write XHTML 5. Now, that standard AFAIK never materialized, but modern browsers will still happily use their XML parser if you serve the document as application/xhtml+xml instead of their default (slower) tag-soup parser to create a DOM-tree out of it and after that their HTML 5 support ensures that they render it correctly. If and when browsers drop their XML parser, I hope they will just parse these docs as HTML and only then would I loose the option of self-closing tags.
- LinAGKar 5y ago
  It didn't "never materialize". It's part of the HTML5 spec (although it's not called XHTML anymore, it's just HTML5 with XML syntax): https://html.spec.whatwg.org/#the-xhtml-syntax https://html.spec.whatwg.org/#the-xhtml-syntax
captainmuon 5y ago
> Ignored means exactly that. HTML does not have xml-style self-closing tags at all. You are answering my complaint by repeating the fact that I complained about? :-D > The goal of the HTML5 parser effort was to create an interoperable and backwards compatible parsing algorithm. Adding self-closing tags to the langage would have tin counter to that goal and would definitely have broken existing code unnecessarily, even though it might have been convenient in some cases. I'd wager that in pre-HTML5 code, the overwhelming amount of cases of <div /> were supposed to mean <div></div> and not <div>.... Why would you even put the slash there if you wanted an opening tag? HTML5 would have been a great opportunity to legalize the former behavior, and that would have broken less code. I distinctivly remember that the self-closing worked as expected even on non-void-tags in quirks mode (not XTML) in the mid 2000s, because at some point I had to fix them after new browser versions came out.

bambax 5y ago

Unpopular opinion: I like XML, and I liked self-closing tags as well. It made more sense. The problem with being lax in what you accept is that it builds immense complexity because you have to deal with a potentially infinite number of special cases. But this books appears excellent. I read the encoding chapter just now, and it was very engaging and informative, explaining the historical reasons why things are the way they are. For example, it says that meta tag about character encoding were initially meant to be read by the server so that it could set the proper encoding header... Which they never did... I did not know that!

heavenlyblue 5y ago
How can a server read a tag if it doesn’t know which encoding to interpret the tag in the first place?
- bambax 5y ago
  I'm guessing, like the HTML parser does: by doing a "pre-parse". The pre-parser is yet another HTML parser, specialized on this task. This is well described in the book and this is how browsers do it today. It seems no web server ever implemented it; it would probably have been a little beneficial because each file would only need to be pre-parsed when it is written on disk (or first read by the server), instead of this being done by every client on every load. It makes me think, maybe other kinds of analysis and normalization could be done by the server, which would allow for simpler (and stricter) browsers.
IshKebab 5y ago
I'm not following what your unpopular opinion is. I think everyone would have preferred it if XHTML had been a success.

LinAGKar 5y ago

HTML5 does have have a strict specification for how it is parsed, unlike previous versions. Also, you can still write HTML5 as XML (XHTML5). It's not talked about much, but it's totally a thing.