How does adding !important change which CSS cascade layer wins?

## The two lists The cleanest way to hold this is to picture two ordered lists per element, both built from the same layer order, read in opposite directions. Normal author declarations, weakest to strongest: ``` first layer → … → last layer → unlayered ``` `!important` author declarations, weakest to strongest: ``` unlayered → last layer → … → first layer ``` Everything about this topic falls out of those two lines. `!important` does not lift a declaration to the top of the normal list; it moves it into a different list that is ordered the other way. ## A worked example ```css @layer base, overrides; @layer base { .btn { color: red !important; } } @layer overrides { .btn { color: blue !important; } } ``` The button is **red**. Strip both `!important` keywords and it turns blue. That reversal is the single most surprising thing about layers, and it is what the question is really testing. ## Why the spec inverts it The cascade already worked this way one level up: `!important` inverts origin precedence, so an important user-agent or user declaration outranks an important author one, protecting accessibility overrides from being stomped by page CSS. Layers reuse that logic. The intent behind an important declaration is "this must not be overridden by ordinary means", so the layers that sit *lowest* in the normal order — resets, base, theme — are the ones whose important declarations are hardest to displace. A low-priority layer is exactly where you would put a value that must survive: a forced-colors adjustment, an accessibility floor, a print rule. ## Unlayered !important is weak The corollary catches people out. Unlayered normal CSS is the strongest normal bucket, so the instinct is that unlayered `!important` must be the strongest important bucket. It is the weakest one. If a third-party widget ships an unlayered `!important` rule you cannot edit, you can beat it with an important declaration inside any named layer you control: ```css @layer fixes; @layer fixes { .vendor-modal { position: fixed !important; } } ``` That is a genuinely useful escape hatch, and it did not exist before layers. ## What is still above all of it An `!important` declaration in an element's `style` attribute is not reachable by this mechanism; it sits above all important author declarations, layered or not. And transitions and animations have their own places in the cascade, so `!important` interacts with them by different rules. Within plain author CSS, though, the two-list model is complete. ## Using it on purpose A deliberate pattern in design systems: ```css @layer tokens, reset, base, components, utilities; @layer tokens { :root { --focus-ring: 2px solid Highlight; } } @layer reset { :focus-visible { outline: var(--focus-ring) !important; } } ``` The focus ring is locked from the earliest layer, so no component or utility can quietly remove it with its own important rule — while ordinary, non-important component styling still behaves normally. That is a defensible use of `!important`; using it in `utilities` to "win harder" is not, because with layers the correct tool for winning is layer position. ## The review heuristic When you see `!important` in a layered codebase, ask which of two things it is. If it is a lock in a low layer, deliberately placed so later layers cannot override it, that is the mechanism working as designed. If it is in the highest layer trying to force a value, it is a leftover reflex from the pre-layer era, and moving the rule to a later layer — or a different layer entirely — is almost always the better fix. The failure mode teams actually hit is important declarations scattered across several layers, at which point the winner is determined by layer order that nobody is reading in reverse, and debugging gets genuinely hard.