In HTML's case, the mass-market adoption and competing browser landscape meant that being anything other than lax and forgiving was a bad strategy for self-pres

In HTML's case, the mass-market adoption and competing browser landscape meant that being anything other than lax and forgiving was a bad strategy for self-preservation: users would simply get frustrated and switch browsers to one that make better sense of the particular broken page. This conundrum explains the complicated and sometimes haphazard hoops that emerged through the efforts of browser-makers, standards-setters, and web developers to move the landscape forward: weird opt-in magic values for stricter handling, IE's eventual "is the page broken?" button, and the like. HTML5 began as a splinter effort to write down what browsers actually do and mix in enough wishlists of what browsers should do, so it's only natural that they decided to codify many rules of handling broken HTML. While I too question whether it was the smart approach, it was definitely an approach that made sense to the stakeholders and authors of HTML5, who were largely actual vendors of browsers and parsers. Even today, that browser vendors have pushed out all sorts of measures like near-mandatory TLS, stricter parsing of HTML is a goal no one really chases. As an appropriate throwback, see Jeff Atwood on this topic in 2007 [1], complete with screenshots of different styles of browser error handling. [1] https://blog.codinghorror.com/javascript-and-html-forgiveness-by-default/ https://blog.codinghorror.com/javascript-and-html-forgivenes...