Plenty of people have also argued that being strict on input would be bad

https://web.archive.org/web/20060613193727/http://diveintoma...

https://friendlybit.com/html/why-xhtml-is-a-bad-idea/

Those arguments are inapplicable here. They’re arguing against XHTML’s particular form of strictness and its failure mode, when compared with HTML, given that both are available to you the web developer; they are not arguing against strictness itself. (Also: if browsers had always rejected invalid documents, rather than having the HTML/XHTML split where one was liberal and one strict, I think we’d have had fewer problems, especially around injection bugs, and people would have been more careful about how they wrote their documents; but that’s fairly subjective.)

If you can choose whether your platform supports strict or forgiving behaviour, security interests will side with strict every time.

And indeed, HTML is no longer loose but rather strict in this protocol sense that we’re talking about, as it defines how all inputs should be parsed, leaving no scope for being liberal in what you accept. (It may surprise people, but among specs of at least moderate complexity, HTML is by far the strictest out there that I know of. I wish more specs were as strict. Actually, JavaScript is probably fairly close.)

Also from the links of dissenting opinions at the start of the dive into mark link, https://web.archive.org/web/20060616150034/http://bitworking... has a good discussion of just where Postel’s law may seem most reasonable to be applicable and inapplicable, with its two-axis (text–binary, data–language) diagram. It’s worth reading and contemplating.