Origins · stage 01
Why nothing is ever removed
The web has no delete key. Every bad idea that shipped is still in the spec.
Stage 01 of six/Origins, piece 3 of 3/Short piece/Next: DNS from the root
The cost of compatibility
When Tim Berners-Lee described the web at CERN in the early 1990s, he had no way to anticipate how many documents would eventually depend on whatever he wrote down. That uncertainty became a structural constraint: once any behaviour reaches users at scale, removing it breaks real pages, and breaking real pages is simply not an option the web's stewards will accept.
The W3C and the WHATWG both operate under this principle, which the WHATWG makes explicit in its design goals: do not break the web. The rule sounds simple and is in practice severe. It means that every parser quirk, every misread of an early draft, every browser innovation that other engines later copied — each of these becomes load-bearing. The spec must describe what browsers actually do, not what anyone wishes they had done.
Vendor prefixes are one sharp illustration. Properties like -webkit-transform were intended as staging areas, temporary scaffolding for experimental features. Web authors used them in production, because production is where real sites live. When the experimental period ended, the prefixes could not be quietly retired — too many live pages depended on them. Other engines had to implement the -webkit- variants anyway, preserving someone else's temporary name as permanent vocabulary.
The cascade itself carries similar sediment. CSS was proposed by Håkon Wium Lie and developed with Bert Bos partly to give authors control without stranding browsers that could not yet render the full model. Decisions made during that negotiation — which properties inherit, how specificity is scored, what the initial values are — were locked in by adoption before the consequences were fully understood. The specificity scoring system, for instance, was a practical compromise, not a derived truth. It is now a permanent part of how the web thinks.
HTML carries the deepest sediment of all. The <b> element was deprecated and then un-deprecated with a redefined meaning. The <table> element was used for layout rather than data in ways its designers never intended; the spec now has to describe the rendering of that misuse accurately. Parsing rules for malformed markup exist not because malformed markup is good but because the web is full of it, and a browser that rejects it is a browser that breaks history.
None of this means the web is static. Features genuinely do get added, and the standards split between the W3C and the WHATWG produced, eventually, a living standard that can evolve continuously. What it cannot do is erase. The archive of the public web goes back further than most institutions, and every page in it was written against whatever the browsers of its day would accept. Changing what those browsers accepted, even retroactively in a specification, is not revision — it is breakage. And breakage is the one thing that is never allowed.
Properties like -webkit-transform were intended as staging areas, temporary scaffolding for experimental features.
The <b> element was deprecated and then un-deprecated with a redefined meaning.