undefined | Better HN

0 pointslmm2y ago0 comments

> You could use an editor that auto-completes elements if you find that they're too long to type.

Maybe, but why do things the hard way? Even if your editor autocompletes, typing the angle brackets is more cumbersome than Markdown.

> Also remember that there are a few common elements, like and <li>, that you usually don't need to close.

Having to remember random trivia like this is exactly why writing HTML is awful.

0 comments

mikae12y ago

> Maybe, but why do things the hard way?

Me and some others don't find it harder. Also, what we write doesn't need a parser to output what the browser needs.

> Having to remember random trivia like this is exactly why writing HTML is awful.

Would not call it “random trivia”, these are quite basic HTML facts[1]. HTML is not XML. My theory is that some people find HTML hard to write because they make make it harder than it has to be.

[1] https://html.spec.whatwg.org/multipage/syntax.html#optional-...

lmmOP2y ago

> Me and some others don't find it harder. Also, what we write doesn't need a parser to output what the browser needs.

If you need an editor with autocomplete to write it comfortably, that's a bigger hassle than a separate postprocessing step that can happen automatically.

> Would not call it “random trivia”, these are quite basic HTML facts[1].

It's absolutely random trivia. These particular four elements don't need closing, except this one might if it's not followed by one of this other long list of possible elements. Why would you ever know (or care about) that unless you enjoy memorizing random lists (I'll bet the reason it's those four is edge cases in a parser that someone wrote in a couple of hours 30 years ago, not any sensible logical classification), or already know the HTML spec because you work as a designer or something?

bentley2y ago

> These particular four elements don't need closing, except this one might if it's not followed by one of this other long list of possible elements.

That’s how it’s worded in the spec, because that’s targeted to browser implementors, not HTML authors. To someone authoring HTML, it’s much simpler: the tag is closed by any encountered opening or closing tag that the tag is not allowed to contain. That’s nothing new to memorize, because you already have to know what elements are allowed in that context. E.g., even in XHTML served with an XML MIME type and parsed with an XML parser, is invalid XHTML, because can’t contain . I already have to know that rule when writing a webpage! Knowing that is equivalent to doesn’t require higher mental overhead.

> I'll bet the reason it's those four is edge cases in a parser that someone wrote in a couple of hours 30 years ago, not any sensible logical classification

Nope, the self‐closing behavior has been present in HTML since the very beginning (inherited from SGML). As for why these elements specifically, it’s because they are among the easiest and simplest to remember due to their definition. <li> can’t contain <li>—the concept doesn’t make sense—so it makes sense for <li><li> to implicitly close the first one. <td> can’t contain <td>—the concept doesn’t make sense—so it makes sense for <td><td> to implicitly close the first one. And so on.

1 more reply

j / k navigate · click thread line to collapse