3 ms·
To a first approximation, this doesn't matter anymore. "Valid HTML" used to be a big deal because when you left the HTML spec you were inviting the various brow
by jerf 2mo ago
To a first approximation, this doesn't matter anymore. "Valid HTML" used to be a big deal because when you left the HTML spec you were inviting the various browsers to interpret your non-standard HTML in differing ways, sometimes quite catastrophically so for the styling or how the Javascript would interact with the page.
This is no longer anywhere near as important as it used to be because HTML5 defines a method for turning more-or-less any sequence of bytes into the same DOM tree: https://dev.w3.org/html5/spec-LC/parsing.html https://dev.w3.org/html5/spec-LC/parsing.html And that's only the beginning of the process. I can't seem to find a good link to the whole 8.2 section of the HTML5 spec but the whole process is freaking huge. But it's defined now.
I hedge on the "more-or-less" because I'm sure there are still bugs in various parsers and perhaps there are pathological sequences that wouldn't be handled by this process, but such sequences would be very, very distant from being HTML at all. But one difference with HTML5 is that the parsers would be considered buggy; in previous versions it could be debatable what the parser should do. HTML5 should fully specify that. If it doesn't that is now a bug in the spec. I would hope it has been banged on enough at this point that any possible remaining corner cases must be pretty small by now.
It is in my considered opinion perfectly sensible to define "HTML" as "what comes out of the HTML5 parsing process" and not really be all that worried about whether this tag does or does not need to be closed before this set of tags but not this other set of tags. It is no longer such an invitation to the browsers to render things completely differently. What was once an academic concern and a user-experience concern is now largely an academic concern.
In fact, if you're handling HTML5 correctly, which is to say, using a real, conformant parser to operate on the resulting parse tree rather than trying to handle it as a string... you can't even tell the difference between "valid" and "invalid" HTML anymore! The parser will wipe that away entirely before the HTML gets to your code. That's how important it is now.
- tomkarho 2mo ago> "Valid HTML" used to be a big deal To a point that there was an actual badge for it.
- account42 2mo agoThat doesn't mean much, there was also a badge for "works best in IE".
- alasdairking 2mo agoIt never mattered. It only mattered that your site worked in the big browsers. Internet Explorer then, Chrome and iOS Safari now. Developers would write their standards-compliant code, boast about it on Slashdot, then put in the hacks and weirdnesses to make it work on IE6. They could have skipped the standards step. I don't say this is a good thing: I probably have XHTML pages on one of my old, private sites, and I ran them through validators. But it was a waste of time, just like, I dunno, using WinUI instead of Electron is now, or not using React. Go with reality.