What does the CSS @layer at-rule do, and how does a layer's position affect which declaration wins?

## The problem layers solve Before cascade layers, the only levers for making one rule beat another were specificity (add a class, an id, repeat the class) and `!important`. Both are one-way ratchets: once a codebase has `#app .card .title` in it, every later rule that wants to win has to be at least that specific, and the numbers only climb. Cascade layers add a dimension that is entirely independent of the selector you wrote. ## What the at-rule does `@layer` declares a named bucket of rules. Two forms matter: ```css /* 1. a statement that only establishes order */ @layer reset, base, components, utilities; /* 2. a block that puts rules into a layer */ @layer components { .card { padding: 1rem; border: 1px solid gray; } } ``` The statement form contains no rules — it just fixes the order of the names. The block form assigns rules to a layer. You can also write an anonymous layer, `@layer { ... }`, which gets a position but no name. ## Layer order is its own sort step When two declarations set the same property on the same element, the browser walks a sequence of comparisons. Among normal (non-`!important`) author declarations, the comparison relevant here runs **layer order first, then specificity, then source order**. That ordering is the whole point: a later layer wins outright, and the specificity of the two selectors is never compared at all. ```css @layer components, utilities; @layer components { #page .btn { color: red; } /* specificity (1,1,0) */ } @layer utilities { .text-blue { color: blue; } /* specificity (0,1,0) */ } ``` An element matching both is blue. The id selector loses because `utilities` was declared after `components`. Reverse the two names in the first line and the same element turns red — you changed the outcome without touching a single selector. ## Specificity is not disabled A common misreading is that layers replace specificity or zero it out. They do not. Inside `utilities`, if `.text-blue` and `#page .text-blue` both matched, the id selector would still win: specificity is computed exactly as it always was and used to resolve conflicts *within* a layer. Layers only decide which layer's declaration is considered the winner when the layers differ. (Zeroing specificity is what the `:where()` pseudo-class does, and that is a different tool.) ## What layers do not reach Layers sort declarations *within* an origin — they do not let author CSS outrank a user's own styles, and they do not touch the user-agent stylesheet's role. The `style` attribute on an element is also unaffected: an inline `style="color: green"` beats every normal author declaration, layered or not. And `!important` does not simply follow layer order — it inverts it, which is a separate rule worth learning on its own. ## How teams actually use it The conventional pattern is a single ordering statement at the top of the entry stylesheet, so anyone reading the file learns the architecture in one line: ```css @layer reset, vendor, base, layout, components, utilities; ``` Everything after that goes into one of those buckets, and the question "why did my rule not apply" gains a cheap first answer: check which layer each rule is in. Utilities placed last win over components by construction, which is exactly the behaviour utility classes need and the reason they historically shipped with `!important`. ## Support Cascade layers shipped in Chrome and Edge 99, Firefox 97, and Safari 15.4 — all in the first quarter of 2022 — so they are safe in any project that is not supporting pre-2022 browsers. There is no partial-support story to reason about: a browser either understands `@layer` or drops the block entirely, which is worth remembering because an old browser ignoring a `@layer` block means those rules simply do not exist for it, not that they fall back to being unlayered. ## The one-line summary A layer is a promotion mechanism for whole groups of CSS. You move a rule up by moving its layer, not by making its selector uglier.