Hacker News Reader

Comment by pbhjpbhj | Hacker News Reader

Don't tables become ambiguous without closing?

>Tables become uncluttered:

If I add a tr, does it nest "than" in the first row or does it move to the second row? Surely it can't nest because each tr effectively has a /tr before it.

    >Raw html tables
    <table>
       <tr>
           <td> are
           <td> easier <tr><td>but ambiguous?
           <td> than
       <tr>
           <td> any
           <td> markdown
           <td> flavor
     </table>

I notice you closed the title, presumably because otherwise it's ambiguous as to whether the paragraph is in the title. It's so easy to make well-formed documents by closing tags intentionally rather than pushing the closing to be inferred by context by different rendering engines I can't see why you would want sloppy mark-up.

View on HN

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

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.

> “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."

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?)

All whitespace remains meaningless. That is, the optional closing tag has nothing to do with a newline. Rather, they are defined as optional if the next tag is one of a set, or their parent is closed.

https://html.spec.whatwg.org/multipage/syntax.html#optional-... is where these are defined. It basically says that a TD remains open until the next sibling td or the tr/tbody/table that it is in is closed.

Wouldn't you need to add another <table> tag if you're nesting?

Reply on news.ycombinator.com