In CSS, where do declarations that are not inside any @layer rank compared to layered ones?

## The rule Every normal (non-`!important`) author declaration that is *not* inside a `@layer` block is treated as belonging to a single implicit layer that is ordered **last**, after all named and anonymous layers. Last means strongest for normal declarations, so unlayered CSS beats layered CSS on layer order alone — specificity is never compared between them. ```css @layer components { #sidebar .card .title { color: red; } /* specificity (1,2,0) */ } .title { color: blue; } /* unlayered, (0,1,0) */ ``` The title is blue. The unlayered rule wins because it is effectively in the final layer, and the (1,2,0) selector in `components` is never even weighed against it. ## Why the spec chose this It makes adoption incremental and safe. If you have an existing stylesheet and start introducing layers for new architecture, the pre-existing unlayered CSS keeps behaving the way it always did — nothing you move into a layer can silently start beating the old code, so a partial migration cannot break the page from the layered side. Layers are opt-in *demotion*: the moment you put something in a layer, you volunteer it to lose against anything unlayered. ## The failure mode interviewers are probing The question is usually asked with a third-party stylesheet in the story, because that is where the model breaks people's intuition: ```css /* your file */ @layer components { .datepicker { border-radius: 0; } } /* vendor.css, loaded normally, no layers */ .datepicker { border-radius: 8px; } ``` You wrote the more deliberate rule, you may even have a more specific selector, and you still lose — because the vendor sheet is unlayered and yours is not. Adding `@layer overrides` after `components` does not help either: *every* named layer is below unlayered. There are two correct moves: 1. **Pull the vendor stylesheet into an early layer**, so it participates in the ordering you control: ```css @layer vendor, components; @import url("vendor.css") layer(vendor); ``` 2. **Leave your own overrides unlayered** deliberately, accepting that unlayered CSS is the top bucket and reserving it for the few rules that must always win. Option 1 is what most design systems do, because it keeps the "everything is in a layer" invariant and makes the override order legible in one statement. ## The `!important` inversion This ranking describes normal declarations only. Among `!important` author declarations the whole layer order flips, and the unlayered group becomes the **weakest** rather than the strongest. So `!important` on an unlayered rule is not the trump card people expect once layers are in play: an `!important` declaration in a named layer beats it. ## How to reason about it in an interview A clean mental model is one ordered list per element, built like this: `[first layer] … [last layer] [unlayered]`, with later beating earlier for normal declarations. Then, separately, the important list is the same sequence read backwards with unlayered at the bottom. If you can draw that list, every question of this shape becomes arithmetic rather than intuition. ## Diagnosing it in practice In browser devtools, an overridden declaration is struck through and the winning rule is shown above it, with layered rules grouped under their layer name — so the tell for this bug is seeing your carefully written layered rule crossed out by a plain-looking selector that would obviously have lost before layers existed. The instinct to reach for `!important` at that moment is exactly wrong; the fix is a layer-order fix. ## Anonymous layers count too A bare `@layer { ... }` block with no name is still a layer, so its rules are also below unlayered CSS. Being unnamed does not make them unlayered — that distinction matters when you inherit a codebase that used anonymous layers for one-off blocks.