> My favorite example is <li>item<li>, which is unfortunately both valid HTML and also an obvious typo.
If it’s <li>item<li> and then the next line is <li>item</li>, it’s an obvious error, but you certainly need to discriminate in that sort of way. Because if your thing goes complaining when I write <li>item<li>item, I’ll be upset.
(In practice, it would almost always be <li>item and then a next line <li>item; when doing things like horizontal menus, you used to use `display: inline-block` and need to avoid whitespace between list items, so you would find <li>item<li>item in serious code, but now you’d use flex and so whitespace between items gets vanished, so you can write it on multiple lines without it affecting the actual layout.)
> Because if your thing goes complaining when I write <li>item<li>item, I’ll be upset.
It does, sorry. No optional tags period.
Giving whitespace more semantic value than what it already has is a dangerous game. I already use whitespace to let the user "talk" with the autoformater and from my perspective that already spends all my whitespace (and weirdness) budget.
First of all, this is awesome work and it's wonderful to see people taking writing plain HTML seriously, because, as you identified, the existing tooling is completely insufficient.
That having been said, I think the reason people largely don't write plain HTML is because the affordances that HTML makes for writeability (like omitting closing tags on <li>, <p>, etc) are frowned upon. If you're going to make all this effort to understand the HTML in the document, it's kind of a bummer to not make it actually understand some core aspects of HTML, aspects that are especially useful when writing it directly instead of treating HTML as a compile target.
When writing code with others, in existing code bases, I will follow house style. (More faithfully than almost anyone else, because I pay attention to these things, both to see what the style is, and to match it.)
When writing code personally, I’ll omit things like </p>, </li>, </head>, </body>, </html>, <head> (which should never have attributes), and attributeless <html> and <body>.
When writing code with others, if I’m in charge, I’ll frequently retain </p> for others’ sensibilities, but I will still often choose to omit </li> (depending on the type of code, definitely).
I specifically dislike </li> because I’ve seen far more problems caused by its presence than by its absence—incorrect nesting and the likes. Also I reckon it’s good that you end up with no whitespace node between your list items (since any whitespace goes into the previous list item), mostly because of old-style `display: inline-block` and such.
If it’s <li>item<li> and then the next line is <li>item</li>, it’s an obvious error, but you certainly need to discriminate in that sort of way. Because if your thing goes complaining when I write <li>item<li>item, I’ll be upset.
(In practice, it would almost always be <li>item and then a next line <li>item; when doing things like horizontal menus, you used to use `display: inline-block` and need to avoid whitespace between list items, so you would find <li>item<li>item in serious code, but now you’d use flex and so whitespace between items gets vanished, so you can write it on multiple lines without it affecting the actual layout.)