You inherit a large legacy application whose pages render in quirks mode. How do you plan the move to standards mode, and what would you tell stakeholders about the risk?

## Why this is a programme, not a commit Adding a doctype is trivial. Absorbing its effects is not, because quirks mode differs from standards mode in ways that change *computed numbers* rather than obviously breaking things. A page that switches modes does not fail loudly; it grows by the width of every padding and border, loses its full-height panes, and silently discards a class of CSS declarations. Those symptoms surface as overflow at some viewport widths, unexpected scrollbars, and text that wraps one line further down — the kind of thing a smoke test passes and a customer reports. So the plan has to be about **containing blast radius and measuring difference**, not about the edit itself. ## The structural advantage: mode is per document The single most useful fact is that the doctype switch runs once per document. That means: - Different routes can be in different modes at the same time. There is no global setting to flip and no shared state between pages. - The unit of migration is a layout template, and the rollback is deleting one line. - Iframes, pop-out windows, print views and generated preview documents are each separate migrations with their own risk. That is what turns an all-or-nothing rewrite into an incremental rollout, and it is the first thing to say in an interview: the strategy follows from the mechanism. ## Inventory before you touch anything Four questions to answer with measurement rather than intuition: 1. **How much CSS assumes the legacy box model?** Every rule that sets a width or height alongside padding or a border is exposed. A codebase that already sets `box-sizing: border-box` on everything is largely insulated from this class, which is why establishing that rule is often the first commit of the migration rather than part of the switch. 2. **How many layouts depend on loose percentage-height resolution?** Quirks mode resolves `height: 100%` where standards mode does not. Full-height sidebars, sticky footers and scroll containers built in the legacy era commonly collapse to content height after the switch. 3. **How much CSS is actually invalid?** Quirks mode accepts lengths without units and hex colours without a `#`. Under standards mode those declarations are dropped, so styling disappears rather than shifting. A linter over the stylesheets finds these cheaply and they are safe to fix *before* the switch, in either mode. 4. **Where are images flush against their containers?** Standards mode restores descender space in line boxes, so images that sat tight against a border get a small gap. Items 1 and 3 are safe to fix ahead of the migration under the current mode — do that work first, so the switch itself carries as little change as possible. ## Sequencing the rollout Order routes by traffic and by layout complexity, and go up the risk curve rather than down it: start with a low-traffic, simple template to validate the process and the regression tooling, then take the highest-traffic templates once you trust it, leaving the gnarliest legacy screens for last when the team has the most experience with the failure modes. Gate each step on visual regression snapshots captured at several viewport widths — before and after, per template. The failure mode of this migration is a subtle numeric shift, which is exactly what pixel diffs are good at catching and human review is bad at. Add an assertion that each migrated route reports `document.compatMode === 'CSS1Compat'` so a later template edit cannot quietly revert it. ## What to tell stakeholders Be honest about the shape of the work: it is measured weeks of layout correction that produces no user-visible feature, carries real regression risk on every page, and is best done while nobody is redesigning those pages concurrently. The argument for doing it is compounding cost: every new component written against a quirks-mode page inherits the wrong assumptions, every hire has to learn the local exception, and every third-party widget documented against standards behaviour becomes a debugging session. The argument for *sequencing* it is that the cost is only paid where you choose, when you choose, because the mode is per document. The alternative worth naming out loud is deliberate inaction: if a legacy area is scheduled for replacement, migrating its rendering mode first is wasted work. Retiring a page beats modernising it. ## The anti-patterns Do not compensate for quirks behaviour in CSS to avoid the switch — that entrenches the exception and hides it from the next reader. Do not switch the shared layout template and "fix what breaks" from bug reports; the bugs that reach you will be the visible ones, and the numeric drift will not. And do not treat a global border-box rule as the whole migration: it covers the loudest difference and none of the quiet ones.