Hacker News Reader

Comment by adamddev1 | Hacker News Reader

On an episonde of Corecursive [1] there's a great discussion/explanation about how following robustness principle can lead to a massive burden in having to develop extremely complex software (like browser engines) because you need to keep supporting everything that was "was allowed" in past versions. They include a quote from Martin Thomas who observed that:

> "The problem with the robustness principle is a flaw can become entrenched as the defacto standard. Any implementation of a protocol is required to replicate the apparent behavior."

If web browsers enforced a very strict protocol of what is "acceptable" HTML and CSS from the very beginning, they would be a lot more simple to build today. Now it's too late and bc of the complexity of "robust" input out there, it's almost impossible for anyone other than one of the giants to create a working implementation.

[1] https://corecursive.com/internet-is-duct-tape/#chuck-norris-...

View on HN

Arguably, would the web exist today as it is if not for robustness principle that also leads to "almost impossible for anyone other than one of the giants to create a working implementation"

I would disagree. For example, suppose we enforced XHTML. Even though it's a mostly dead standard that was never very popular, there are plenty of free and very functional validators around. You don't need to be a multi-billion dollar company to close your tags.

Similarly for JS, strict mode did not ruin the internet. Sure, there is a lot of old JS code around that may or may not run in strict mode. That is not because it is any harder to write correct JS in strict mode than it is in "sloppy" mode, but the "robustness principle" has just burdened us with a lot of legacy crap that wouldn't otherwise exist. I would argue that the web would be better if JS had been strict from the start.

Explain to me why XHTML did not stay with us?

Because nobody cared much for it, and it didn't give us what we actually wanted, which HTML5 did...

XHTML never really had a chance because the dominant browser at the time, Internet Explorer, never supported it. Since people were going to have to deal with all of IE's quirks anyways there was little appetite for putting in the effort to support XHTML too.

It depends on what you mean by 'XHTML.'

One of the possible definitions is a mode of HTML that was forced to be strictly validating by an XML parser. Adoption of this was hurt by the fact that XHTML-delivered-as-XHTML didn't work correctly in the dominant browser of the time. But HTML5 also delivered a fully-specified parser that explained how to handle tag soup correctly, which meant the problem trying to be solved here (having to parse HTML files into a DOM) was solved in a different way.

Another possible definition is the XHTML 2.0 definition, which tried to rip out a lot of HTML features and replace them with more semantic definitions and was largely an effort that was entirely divorced from reality (to the point of driving out the web browser implementors entirely from the working group).

HTML5 rules didn't solve the problem of parsing HTML files into a DOM. Instead it mandated the existence of HTML files which, when parsed, converted to HTML, and parsed again, produce a different tree than the first time around. This harmful property can be used to develop XSS exploits like https://research.securitum.com/mutation-xss-via-mathml-mutat....

It didn't survive because HTML5 came along with very well defined and strict parsing rules.

You don't need closing tags for a specification to be strict. As long as you define the parsing rules rigorously as HTML5 does, there is little benefit in XML compliance and there is in a well defined non-XML standard as it is mostly backwards compatible.

Big differences between xhtml and js-strict are:

- strict mode is a much more local opt-in, it’s difficult to opt others into strict mode, and thus the likelihood of respecting strict mode is high

- js is much less subject to embeddings, with xhtml even back then there was a long tail of CMS type content which would suddenly break the page hard and with no actionable recourse for the viewer

- finally strict mode came with a bunch of benefits e.g. new syntax / constructs, etc, for the person opting into strict mode, but unless you were an XML-head with an entire XML-based processing pipeline, what did XHTML give you? Additional pain when authoring content is about all.

I think you could have the same issue with a stricter format.

The "impossibility" is not the quirks and ends of HTML - is adding all the 100s of frameworks on top, like 5 accelerated graphic options (Canvas, WebGL, SVG, CSS Animations, WebGPU), all kinds of type-setting-foo including math rendering, real-time communications, 2 optimized-to-death-by-experts languages (JS, WASM), storage options, sandboxes, audio, video, MIDI, and synthesizer capabilities, and so on...

The link also mentions the (useful) name for this phenomenon, Hyrum's Law: "With a sufficient number of users of an API, it doesn’t matter what you promise. Any observable behavior of your system will be dependent upon by somebody."

Related xkcd variant: "Every change breaks someone's workflow."

https://xkcd.com/1172/

Reply on news.ycombinator.com