Every major browser engine shipping today contains a rendering path whose explicit purpose is to be wrong. Wrong in the specific ways that Netscape Navigator 4 and Internet Explorer 5 were wrong, preserved with the fidelity of a museum restoration.
The WHATWG's Quirks Mode Standard, a living document last updated September 2025, codifies these behaviors.1 It specifies exactly how box widths should be miscalculated, how images should be misaligned in table cells, how font sizes should fail to inherit correctly. The standard's own preamble calls the entire architecture of multiple rendering modes "basically a historical accident." Then it proceeds, for several thousand words, to define that accident with normative precision.
Someone maintains this. Someone writes commits against it, reviews pull requests, argues about edge cases in behaviors that originated in software that stopped shipping before some of their colleagues were born. We wanted to talk to that person. So we invented one.
Petra Backcompat is a fictional senior rendering engineer at a major browser vendor. She has worked on layout compatibility for fourteen years. She is not real, but her codebase is.
You maintain code whose stated purpose is to reproduce bugs from the 1990s. How do you describe your job at parties?
Petra: I usually say I work on browsers and then change the subject. If someone pushes, I tell them I'm a custodian. Which is accurate. I maintain a room that everyone agrees shouldn't exist but that you absolutely cannot demolish because load-bearing walls from three other buildings run through it.
The follow-up question is always "can't you just fix it?" and I've learned that explaining why you can't takes longer than the party.
The WHATWG spec describes the whole system as "a historical accident." What's it like working on something whose own documentation says it shouldn't exist?
Petra: Clarifying, actually. Most infrastructure pretends it was designed. The quirks spec is one of the few honest documents in the standards world. It opens by saying, essentially, this was a mistake, and in hindsight we would have done it differently, and here is the precise specification of that mistake.1 I find that refreshing. Most software I've worked on has pretended its compromises were intentional. Quirks mode just says: we're here, it's wrong, let's be wrong correctly.
What does "wrong correctly" look like in practice?
Petra: Take the box model. In no-quirks mode, when you set an element's width to 200 pixels, padding and borders get added on top, so the actual rendered box might be 240 pixels wide. In quirks mode, padding and borders are included in that 200 pixels. The content area shrinks to accommodate them.2 IE5 did it that way. Millions of pages were built assuming that behavior. So in quirks mode, we reproduce it exactly.
And here's the thing that keeps me up at night in a good way: the IE5 interpretation arguably made more intuitive sense. When you say a box is 200 pixels wide, most people mean the box should be 200 pixels wide. CSS eventually acknowledged this with box-sizing: border-box.
The bug won. It just took fifteen years to be recognized as a feature.
The spec also preserves behaviors around image alignment in table cells, font size inheritance, case sensitivity in CSS selectors...
Petra: Each one is a named fossil. The font inheritance one is the one I think about most. I don't want to say "favorite." That implies affection. It's more like the one I respect.
In old browsers, tables didn't inherit font sizes from their parent elements. So if you set your body font to 80% and your table font to 80%, you got 80% in the table, not 64%. Standards mode does the math correctly. Quirks mode does it the way people expected it to work when they didn't understand CSS inheritance.3 Which was almost everyone in 1998. Including, I suspect, some of the people writing the spec.
The rendering mode is triggered by the DOCTYPE declaration. But the DOCTYPE itself has a strange history.
Petra: The DOCTYPE began as a formal declaration of document structure. It told a parser which DTD to validate against. No browser ever actually used it for that.4 Its only real function, the only thing it has ever done in a browser, is flip a switch between rendering modes. <!DOCTYPE html> is the incantation that says "please don't be IE5." Five words. The entire semantic purpose it was designed for was never implemented. The vestigial purpose is what everything depends on.
And then there's the JavaScript side. You can check document.compatMode and it returns either "CSS1Compat" or "BackCompat". Not "legacy." Not "broken." Not "quirks." BackCompat. The system's own name for itself chose neutrality. I've always liked that. No judgment. Just a description of direction.
You mentioned the renaming of "standards mode" to "no-quirks mode." Why does that matter?
Petra: Because the old name implied a hierarchy. Standards mode was correct; quirks mode was deviant. The renaming acknowledged something the spec community had been dancing around for years: both modes are standardized. Both are specified. Both are maintained. The only difference is whether the quirks are present or absent. Neither mode is more "real" than the other anymore.
Even the vocabulary of correctness got laundered.
Your work has shifted over the years. It's no longer just about preserving behaviors.
Petra: Right. When Edge moved to Blink in 2020, that raised the bar for consistency across engines.5 The job now is making sure that Blink, Gecko, and WebKit are all wrong in exactly the same way. If one engine's quirks mode renders a 2001 intranet page slightly differently than another's, that's a bug. A bug in our bugs. The engineering challenge of coordinated wrongness is genuinely harder than it sounds. You're reverse-engineering consensus about mistakes that three different teams made independently twenty-five years ago.
Who's still triggering quirks mode in 2026?
Petra: Enterprise intranets. Government systems. Banks. The kind of pages where someone built an internal tool in 2002, it works, nobody has a budget to rebuild it, and the DOCTYPE line was never there because the developer was copying from a "How to Make a Web Page" book from 1999 that didn't mention it. Those pages will outlive me. They'll outlive the browsers. Someone will be emulating my quirks mode implementation in 2060.
Does it ever bother you? Spending your career maintaining something its own authors say shouldn't exist?
Petra: (long pause)
Early on, I had the instinct to fix things. You see the box model doing the wrong calculation and your hands want to correct it. But the commitment here is to something larger than correctness.
Every page that was ever built and put online, even badly, even incorrectly, made a kind of promise to whoever might visit it. Quirks mode is how we keep that promise.
The spec says these behaviors are "necessary to support."1 Not "retained for historical interest." Necessary. I've made my peace with that word. Took me about six years, but I got there.
Is there a plan to eventually remove quirks mode?
Petra: No.
Petra Backcompat is fictional. Her codebase is not. The Quirks Mode Standard is maintained as a living document by the WHATWG and was last updated on September 17, 2025.
Footnotes
-
WHATWG Quirks Mode Standard (Living Standard): https://quirks.spec.whatwg.org/ ↩ ↩2 ↩3
-
MDN Web Docs — Quirks Mode and Standards Mode: https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Quirks_mode_and_standards_mode ↩
-
Wikipedia — Quirks Mode: https://en.wikipedia.org/wiki/Quirks_mode ↩
-
WHATWG HTML Standard — Infrastructure: https://html.spec.whatwg.org/dev/infrastructure.html ↩
-
Microsoft Edge Chromium transition (Edge 79, January 2020): https://en.wikipedia.org/wiki/Microsoft_Edge ↩