> Parsers should be fail-fast and deterministic, this is one of the many problems of the web. Developers don't notice their incorrect code due to this and without noticing rely on the implementation-specific way one browser handles the issue.
This was XHTML documents when sent with the correct Content-Type. "Just don't display anything if the document is malformed" is worse for users if devs still create malformed documents.
The only reason developers write malformed documents was because they can get away with it. And yet, millions of lines of code are written every day in programming languages that absolutely do not accept malformed code, and that all works out just fine.
Another problem with it is that everyone who can get something to display in their browser suddenly thinks of themselves as a developer.
How does such a system reconcile the need to be opt-in to maintain backwards compatibility with the web as it exists with the likelihood that the audience you want to reach (developers who can't be bothered to Do It Right) are just the ones who will not opt in?
Ancient history now, but HTML5 was developed by WHATWG specifically as pushback against priorities of W3C at time (chief among which was push for XHTML).
That's not to say things cannot be improved, just to say this has all happened before and it will all happen again (and it is worth paying attention to what happened last time).
This was XHTML documents when sent with the correct Content-Type. "Just don't display anything if the document is malformed" is worse for users if devs still create malformed documents.