5 ms·

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 deve

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-is-an-html-color https://corecursive.com/internet-is-duct-tape/#chuck-norris-...

heavenlyblue 5y ago
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"
- Thiez 5y ago
  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.
  - heavenlyblue 5y ago
    Explain to me why XHTML did not stay with us?
    - tomtomtom777 5y ago
      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.
    - coldtea 5y ago
      Because nobody cared much for it, and it didn't give us what we actually wanted, which HTML5 did...
    - magila 5y ago
      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.
    - jcranmer 5y ago
      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).
      - 5y ago
- coldtea 5y ago
  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...
SilasX 5y ago
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/ https://xkcd.com/1172/

heavenlyblue 5y ago

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"

Thiez 5y ago
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.
- heavenlyblue 5y ago
  Explain to me why XHTML did not stay with us?
  - tomtomtom777 5y ago
    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.
  - coldtea 5y ago
    Because nobody cared much for it, and it didn't give us what we actually wanted, which HTML5 did...
  - magila 5y ago
    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.
  - jcranmer 5y ago
    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).
    - 5y ago
coldtea 5y ago
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...

SilasX 5y ago

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/ https://xkcd.com/1172/