@yoz is right. If only web browsers didn't render bad HTML, the web would not be so much better, it would not have worked. There is a historical precedent to

@yoz is right. If only web browsers didn't render bad HTML, the web would not be so much better, it would not have worked. There is a historical precedent to show it. I remember when XHTML was the future, about 2002-2005. Pages were loaded in Firefox by a XML parser. If the page was invalid XML for any reason, Firefox would render a parser error message: "error X in line Y, column Z" with a copy of the offending line and a nice caret under the error position thanks to a monospace font. Wrong percent encoding? No page rendered. Invalid entity? No page rendered. Messy comment separator (two minus signs)? No page rendered. Inserting an element where not allowed ? I guess no page rendered. This is nice for a rigorous developer perspective, I appreciated it. But (I used to hate that but a wise person sees the world as it is) it is a catastrophe for real-world adoption. Fixing one static page on your dev machine, thanks to the error message, is a thing. Making a dynamic website become practically impossible unless all your engineers are extremely rigorous and well-organized, and/or use a framework that generates guaranteed valid XHTML any time. But all frameworks (except a few unknown ones) had (have?) no notion of a document tree or proper escaping but just concatenate text snippets. From a business perspective, it means your website is much more difficult to get displayed at all (let alone correctly displayed). And even if it works today, it can blow up at any time because of a minor fix anywhere. Worse, the pages your team tests are okay, but real-world visitors will hit some corner case and get an error message intended for a developer. One may have hoped that some cleaner framework would appear and serve guaranteed valid XHTML any time. I would have liked this option. Developer would create tree hierarchies in memory and serialize them into XHTML. Please commenter name some that do and how popular they are. Did it save XHTML? That aspect may be the reason number one why XHTML was ditched in favor of HTML5: the web worked because it did a best effort to render invalid pages. Any solution that strays away from this principle will not be adopted at large. Meta bonus: we're discussing the HTML level but this kind of discussion we would have had at any other level, had the stack been consistent a few levels higher (script) or lower (HTTP, TCP). It's funny how HTTP and TCP looks like they just work, but they have their own corner cases and spec holes. The ecosystem just happened to have mostly converged on a few implementations that mostly work okay. (No, let's not talk about IPv4, NAT, and the like. ;-)