> If the browser misinterprets, you have a hard time finding out what went wrong.
This is what HTML validators are for.
Browsers should do their best to interpret the page authors intention and actually display a page. The developer doesn't always have 100% control over the page markup (think about user generated content, ads etc...)
Sorry, that's silly. Web pages break all the time.
If they would break because of invalid HTML, they would also already break during your tests.
If you use some HTML injection services like ads or analytics that make valid HTML invalid, then it's great that it breaks because it will show you immediately on your tests that these services suck.
If browsers would error out on invalid content then those services would either provide valid content or they would go bust.
And XML/XHTML is much easier to parse and for producing valid content than HTML because it is much more consistent and has less history package than HTML.
It is just that today, we still have tag-soup and error-tolerant parsers in the browsers and of course lots and lots HTML producer are producing shitty HTML and you can't just switch on a strict parsing.
But if history would have taken a slightly different turn, we would be talking about XHTML5 and not HTML5.
That's a good point, but I wasn't necessarily thinking it should error out to render nothing at all.
What I would like is if somehow the browser could insert an error class name into the offending element so that in my CSS I could give it a set of rules to make it stand out after render.
This is what HTML validators are for.
Browsers should do their best to interpret the page authors intention and actually display a page. The developer doesn't always have 100% control over the page markup (think about user generated content, ads etc...)