Raise your hackles about the choice not to fail fast if you want, but when they fail, they do fail deterministically. It's a too-common myth that they don't. (A little perverse that people who make a big deal out of others unable to follow spec, but by doing so prove they haven't checked what the spec says—because if they did, they'd know this...)
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.
Another problem with it is that everyone who can get something to display in their browser suddenly thinks of themselves as a developer.
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).
Yes, that is part of the problem. 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. Then 3 versions later or in a different browser they whole house of cards comes tumbling down.
> One developer can do with the web what 10 couldn‘t do with native
Building a non-trivial app is always faster to do native. By a huge margin.