FORGE
Services About Blog
The spec that embraced imperfection — and saved the web
Engineering 23 March 2026 · 5 min read

The spec that embraced imperfection — and saved the web

In 2004, three browser vendors wrote a letter to the W3C. The message was polite. The subtext was not. What happened next is the best argument in software for building from reality rather than from theory.

RO
Robert Okoroafor
FORGE

In 2004, three browser vendors — Apple, Mozilla, and Opera — wrote a letter to the W3C. The letter is polite. The message is not.

The W3C had decided that HTML was finished. The future was XHTML — HTML rebuilt on XML's strict rules. Well-formed or nothing. A single misplaced tag and the browser would refuse to render the page. This was considered progress.

The browser vendors disagreed. They formed a new working group, called it WHATWG, and started writing a different kind of specification. Not the web they wanted, but the web that existed.

The specification that described reality

The WHATWG spec was unusual. When browser behaviour diverged from what the spec said should happen, the spec changed. Not the browser — the spec.

This sounds like giving up. It was the opposite. A specification that ignores implementation reality is not a specification — it is a wish list. Browser vendors implement from wish lists unevenly. Users experience the inconsistency. Developers work around it. The gap between spec and reality compounds with every version.

The WHATWG spec reduced the gap by starting from the other side. Describe what browsers actually do. Define the correct behaviour where there is divergence. Make the description so precise that a new browser could implement it from scratch and achieve interoperability without reverse-engineering existing browsers.

When bugs become standards

The spec contains this sentence, rendered almost apologetically: implementation bugs have often become de-facto, and now de-jure, standards, as content is often unintentionally written in ways that rely on them before they can be fixed.

This is not a disclaimer. It is a description of how software ecosystems actually work.

When every major browser implements the same bug the same way, millions of pages are written against that bug. The bug is now load-bearing. Fixing it breaks the pages. The correct choice — the only honest choice — is to standardise it.

The alternative is ideological purity at the cost of the web itself.

Backwards compatibility as discipline

The W3C's XHTML approach broke backwards compatibility deliberately. Old pages that were not well-formed XML would fail. The reasoning was sound: bad markup is bad, therefore require good markup, therefore the markup improves.

The markup did not improve. Authors used authoring tools that produced the markup. Authoring tools did not update overnight. Users visited pages that failed. The web did not become better-formed — it became unreachable.

The WHATWG principle — do not break the web — is not a soft commitment. It is an engineering discipline. It asks: if we change this behaviour, what existing content does it affect? It requires the answer before proceeding. The constraint is hard enough that many improvements become impossible. That is the point.

What this teaches about building platforms

The HTML story is about the difference between a platform and a product. A product can require users to upgrade. A product can deprecate its own API, break old integrations, and ask developers to adapt. The product controls the relationship.

A platform cannot do this. A platform is made of the content built on it. Changing the rules changes the foundation under existing content. The content was not consulted. The people who built it may not exist anymore.

Platforms that understand this write specifications the way WHATWG does: start from what is real, define what is correct, hold the line on anything that would break what is already there. Every new feature carries a debt of compatibility. Spend it carefully.

The quiet lesson

The introduction to the HTML specification is twenty pages that most developers will never read. It contains the clearest account I have seen of how a technical standard earns the right to exist: by taking the existing world seriously, even where it is broken, even where the breaks have calcified into requirements.

The web works because the people who maintained it chose accuracy over elegance. They chose the web that existed over the web they would have designed.

That trade is available to any platform willing to make it.

New project

Start a
project.

Discovery call
Loading calendar…