How does the browser establish the order of CSS cascade layers, and what happens when you re-open a named @layer block later in the same stylesheet?

## First appearance fixes the position The cascade sorts layers by the order in which their names are **first encountered** while parsing the stylesheet. Everything after that first encounter is appending, not reordering. ```css @layer base { a { color: teal; } } @layer utilities { .u-red { color: red; } } @layer base { a { text-decoration: none; } } /* appends to base, base stays first */ ``` Here the order is `base`, then `utilities`, and the third block does not promote `base` above `utilities`. If it did, layer order would depend on which file happened to be concatenated last, and the whole mechanism would be as fragile as the source order it was meant to replace. ## The statement form is the intended pattern Because first appearance wins, you can declare the entire architecture in one line before any rules exist: ```css @layer reset, vendor, base, layout, components, utilities; @import url("vendor.css") layer(vendor); @import url("components.css") layer(components); @import url("base.css") layer(base); ``` The imports are deliberately out of order to make the point: the override order is `reset < vendor < base < layout < components < utilities` no matter how the files are loaded or bundled. This single statement is also the best documentation the stylesheet has — a reader learns the whole override policy from one line. ## Undeclared names are appended If a block uses a name that no statement listed, that name joins the order at that moment, after every layer already known: ```css @layer base, components; @layer debug { .outline * { outline: 1px solid red; } } /* debug lands after components */ ``` That is convenient but also the main way a codebase drifts: a typo like `@layer compoents { ... }` silently creates a brand-new layer at the end instead of adding to `components`, and because that new layer is *last*, the rules start winning more than intended rather than failing loudly. ## Nested layers Layers nest, and a nested layer's full name is dotted: ```css @layer framework { @layer base, theme; } @layer framework.theme { .btn { background: navy; } } ``` The inner order (`framework.base` before `framework.theme`) is resolved inside the parent, and the whole `framework` group keeps its own position relative to sibling top-level layers. Nesting matters when you ship a library: you expose one outer layer name, and consumers can slot your entire sub-order into their own architecture with `@layer reset, framework, app;` without knowing your internal names. A sub-layer can never escape its parent — `framework.theme` still loses to any top-level layer ordered after `framework`. You can also reach a nested layer by nesting the blocks instead of dotting them; `@layer framework { @layer theme { ... } }` is equivalent to the dotted form. ## Anonymous layers `@layer { ... }` with no name creates a layer at that position that has no identity: ```css @layer { .a { color: red; } } @layer { .b { color: blue; } } ``` These are two *different* layers, not one, and neither can be referenced, reopened, or targeted by an ordering statement. They are useful for a self-contained block you want demoted below unlayered styles, and a liability anywhere you might later need to insert something between them. ## Why this matters in review The practical rules that fall out of this: - Put one `@layer a, b, c;` statement at the top of the entry stylesheet and treat it as the source of truth. - Never rely on the order of `@import`s or bundler output to establish layer order. - Treat an unlisted layer name in a diff as a smell — it is either a typo or an architecture change that should have been made in the ordering statement. - Prefer named layers over anonymous ones in shared code, so future rules can be appended to them. ## The compact answer Order comes from first mention; later mentions only add rules. Declare the order once, deliberately, and every other file becomes order-independent.