You inherit a CSS codebase full of selectors like `#app .sidebar ul li a.active`. How do you get specificity down across it incrementally, without a rewrite and without visually breaking pages?

## Why editing the old selectors first is the wrong opening move A chain like `#app .sidebar ul li a.active` is not just heavy, it is also load-bearing in ways the file does not record. Somewhere else there may be a lighter rule that has been silently losing to it for three years, and the page looks right *because* it loses. Lower the chain's weight and that dormant rule wakes up. Do that across a few hundred selectors and you are shipping a diff whose visual consequences nobody can predict from the diff itself. So the sequence is: contain, then replace, then delete. Never "go through and simplify the selectors". ## Step one — inventory You need to know the shape of the problem before choosing tactics. Useful measurements: - distribution of selector weight across the codebase, and where the heavy tail lives - count of `!important` declarations, and whether they cluster in a utilities file (a convention) or in feature code (a symptom) - a specificity-over-source-order chart: every point where a later rule is *weaker* than an earlier one that targets the same thing is a place someone will eventually escalate. stylelint's `no-descending-specificity` flags this class of problem directly - which selectors are actually matched by live pages, so you know what is dead ## Step two — contain **Cascade layers.** Put the whole legacy stylesheet in a layer declared first: ```css @layer legacy, components, utilities; @layer legacy { /* the inherited stylesheet, unchanged */ } ``` Nothing changes visually: the legacy rules still resolve against each other exactly as before, because within a single layer normal specificity and order rules still apply. But anything you write in `components` — or unlayered — now beats them all for normal declarations, at single-class weight. That single move ends the escalation pressure immediately, which is what makes everything after it affordable. Layers are supported across the major browsers since 2022 (Chrome 99, Firefox 97, Safari 15.4). **`:where()` neutralisation.** Where wrapping a whole file is impractical — a vendor bundle, a file you can only touch rule by rule — `:where()` collapses part of a chain to zero while matching identically: ```css /* before: (1,2,3) */ #app .sidebar ul li a.active { color: crimson; } /* after: (0,1,1) — same elements match */ :where(#app .sidebar ul li) a.active { color: crimson; } ``` This is surgical and reversible, and it is the tool for the worst individual offenders. **Do not** reach for `!important` as the migration mechanism. It buys the same containment for one release and leaves a worse problem behind. ## Step three — stop the growth Apply the ceiling to new code before you fix old code. A specificity cap via stylelint's `selector-max-specificity`, plus `declaration-no-important` with a single allowlisted utilities file, scoped so that legacy paths are excluded or baselined. This matters more than it sounds: a migration that takes two quarters while the old pattern keeps being copied into new files never converges. ## Step four — migrate by component, not by selector Pick a component. Write its flat replacement in the new layer, delete the legacy rules for it, check it visually, ship. Order the work by traffic and churn: the components people change every week pay back immediately, and the settings page nobody has touched since 2019 can wait or die. The safety net here is visual comparison rather than unit tests, because the thing you are changing is which declaration wins, and that only shows up when rendered. Whatever screenshot-comparison tooling the project already has is enough; the discipline is one component per change so a difference has one obvious cause. ## Step five — delete The migration is only finished when the legacy layer is empty. Track its size as the metric, because a half-migrated codebase where both the old chain and the new flat rule exist is worse than either — a reader now has to work out which one is live. Coverage tooling that reports unused selectors tells you which legacy rules can go without a replacement at all; on old codebases that is usually a substantial fraction of the file. ## The honest caveat Some of this cannot be fixed from the stylesheet. If the markup has no class to hang a flat rule on — generated templates, a CMS, a widget you do not own — the chain is the only handle you have. Neutralise its weight with `:where()`, isolate it, document why, and move on. Perfect flatness is not the goal; removing the pressure that makes weight climb is.