3 ms·

Implicit end tags aren’t sloppy at all. Documents using them are completely unambiguous and completely well‐formed, as has been the case since the inception of

Implicit end tags aren’t sloppy at all. Documents using them are completely unambiguous and completely well‐formed, as has been the case since the inception of the language. In fact, the fact that implicit end tags and implicit elements are unambiguous is why they exist as a feature at all. <td> cannot contain <tr>—the idea doesn’t make sense—so <td> followed by <tr> implicitly closes the <td>. <li> can’t contain <li>, so it implicitly closes. <p> can’t contain <p>, and so on. XML doesn’t help at all here: even if you use a strict XML parser, you can make a construct like “<p><p></p></p>”, and it’ll be ostensibly “well‐formed,” but it won’t be valid HTML. The XML way of “make everything verbose, even when it’s already unambiguous” was a late addition to the language. And it leads to surprise like what’s visible throughout this thread, such as people expecting <div /> to act like <div></div> when it really acts like <div>.

dragonwriter 3y ago
The XML way is very good for XMLs purpose, which is enabling generic tooling that doesn't need to understand the semantics of the particular application language, which is great for building a foundation for tooling to support thousands of application languages most of which will have very few users so it is very good if much of the tooling cost is smeared across lots of other languages. HTML is important enough that it warrants direct investment in tooling and doesn’t need the XML approach.
von_lohengramm 3y ago
> “make everything verbose, even when it’s already unambiguous” The idea is to make the language less context-sensitive and more consistent. It's better if the meaning of `<p>` and `<p/>` don't change based on the parent tag. Now, obviously they failed at making the semantic changes necessary to achieve the goal, but a true XML-based language would've been far simpler both for humans and computers than what we've got now. Most of the author's points are entirely valid, but the conclusion really should've been "HTML is bad."
- bentley 3y ago
  But the meaning does change based on the parent tag. <p> is not allowed to be nested, just like <li> and many other elements. Those are rules anyone writing markup has to remember, whether XML or not. Allowing <li> to close the previous <li> is a natural extension of that rule, and strikes a good balance between the rigor of XML and brevity of Markdown, whose context rules I find to be both less consistent and incredibly difficult to remember. (Can a list contain a list? Does ^ superscript a whole line or just a word? What elements can contain a table?)

dragonwriter 3y ago

The XML way is very good for XMLs purpose, which is enabling generic tooling that doesn't need to understand the semantics of the particular application language, which is great for building a foundation for tooling to support thousands of application languages most of which will have very few users so it is very good if much of the tooling cost is smeared across lots of other languages. HTML is important enough that it warrants direct investment in tooling and doesn’t need the XML approach.

von_lohengramm 3y ago

> “make everything verbose, even when it’s already unambiguous” The idea is to make the language less context-sensitive and more consistent. It's better if the meaning of `<p>` and `<p/>` don't change based on the parent tag. Now, obviously they failed at making the semantic changes necessary to achieve the goal, but a true XML-based language would've been far simpler both for humans and computers than what we've got now. Most of the author's points are entirely valid, but the conclusion really should've been "HTML is bad."

bentley 3y ago
But the meaning does change based on the parent tag. <p> is not allowed to be nested, just like <li> and many other elements. Those are rules anyone writing markup has to remember, whether XML or not. Allowing <li> to close the previous <li> is a natural extension of that rule, and strikes a good balance between the rigor of XML and brevity of Markdown, whose context rules I find to be both less consistent and incredibly difficult to remember. (Can a list contain a list? Does ^ superscript a whole line or just a word? What elements can contain a table?)