Where Browsers Differ · stage 06
The same spec, two results
A specification describes what should happen. It cannot always describe every detail of how — and that gap is where browser engines diverge.
Stage 06 of six/Where Browsers Differ, piece 1 of 3/Full piece/Next: Prefixes and their legacy
Where specifications end and engines begin
A web standard is a document, not a program. The W3C or WHATWG writes down the intended behaviour in prose and algorithms, often with careful precision, but a specification is only as complete as its authors could foresee. Edge cases accumulate. Interactions between features compound. And where the text runs out, each engine — Blink in Chrome and Edge, Gecko in Firefox, WebKit in Safari — makes its own judgment call.
Some divergence is accidental. A specification might describe the output of a process without fully constraining the intermediate steps, and two implementors, both reading the same prose in good faith, produce engines that agree on the common case and disagree on everything adjacent to it. Floating-point rounding in layout arithmetic is a classic source of sub-pixel differences that are individually meaningless and collectively maddening when you are trying to align things precisely across browsers.
Other divergence is deliberate — or at least knowing. An engine ships a feature before the specification has fully settled, reasoning that real-world usage will inform the final design. That reasoning is not always wrong. But it means that the spec, when it eventually hardens, may not match what is already in the wild. The feature that shipped first tends to become the reference point, whether or not it was the cleanest design.
The gap between "valid" and "identical"
Conformance suites exist precisely because written agreement is not the same as behavioural agreement. A test suite operationalises the specification: it turns prose into pass/fail assertions that engines can run against themselves. The W3C maintains thousands of these tests across CSS, HTML, and related specifications. Engines that pass a test are conformant on that point; engines that disagree on a test expose a real gap.
But conformance suites are never exhaustive. Writing a good test requires imagining the failure mode first, and some failure modes only surface once a feature meets real content in production. Vendor prefixes illustrated this acutely — browsers shipped prefixed properties that were functionally similar but subtly incompatible, and by the time the unprefixed standard arrived, years of content had been written against the divergent behaviour. Removing or correcting that behaviour became nearly impossible.
CSS layout is where the visible pain concentrates. Flexbox, during its long specification journey, went through significant algorithmic changes. Older WebKit-based browsers shipped an early draft; the final specification diverged from it. The result was two things with the same name — display: flex — that did not behave the same way. Developers had to account for both. The cascade itself, as Håkon Wium Lie and Bert Bos designed it, is well-specified at the rule level; the problem arises at the rendering level, where layout and paint interact with hardware, font metrics, and platform-specific text rendering in ways no single document can fully anticipate.
Living with the gap
The practical consequence for someone building on the web is that the specification is a floor, not a ceiling. It tells you what behaviour is guaranteed; it does not tell you that every browser will agree on what lies just outside the tested area. Reflow and repaint cycles, sub-pixel geometry, the precise timing of when a font triggers a layout shift — these are areas where the specification may be silent or underspecified, and where testing against real engines remains the only reliable source of truth.
Standards bodies are aware of this. The WHATWG's living standard model and the W3C's increased investment in cross-browser test infrastructure both reflect an understanding that a specification only becomes trustworthy once multiple independent implementations agree on it and a test suite proves it. Agreement on paper is where the work begins, not where it ends.
The result was two things with the same name — display: flex — that did not behave the same way.
Removing or correcting that behaviour became nearly impossible.
The stage in a room: specifications leave gaps, and each engine fills them differently.