The Cascade in Production

A freshly started CSS file is clean. By the time a codebase is two years old and a dozen engineers have touched it, the same file often contains a trail of !important declarations, ID selectors added specifically to win specificity fights, and override rules that exist solely to cancel earlier rules. This is not a failure of discipline — it is the predictable result of CSS's global scope and the specificity-based resolution model. Cascade layers are the first structural fix the CSS specification has introduced for this problem.

How specificity wars start

The cascade resolves conflicts by comparing selector specificity. The more specific rule wins. This works fine in a small codebase where one person holds the whole stylesheet in mind.

In a team, someone writes:

/* component author */
.card { padding: 16px; }

Later, someone tries to add a utility class:

/* utility author */
.p-0 { padding: 0; }

.p-0 does not override .card on a <div class="card p-0"> — both selectors are one class, so specificity ties, and source order (.card was declared first) wins. The utility author "fixes" this:

.p-0 { padding: 0 !important; }

Now the component author's variations break because !important beats everything. They escalate:

#main-content .card { padding: 16px !important; }

Three months later, the stylesheet is a specificity arms race. Every new developer reads the existing rules, sees !important everywhere, and concludes that is the local style. The cycle accelerates.

Cascade layers

@layer gives you a mechanism to group stylesheets into explicitly ordered layers. Within those layers, the normal cascade still applies. But when rules from different layers compete, the layer order wins — specificity is not consulted.

Declare the layer stack once, at the top of your main stylesheet:

@layer reset, base, components, utilities;

This single line establishes that utilities beats components beats base beats reset — no matter how specific any individual rule is:

@layer reset {
  *, *::before, *::after { box-sizing: border-box; }
  body { margin: 0; }
}

@layer base {
  p { line-height: 1.6; color: #333; }
  a { color: var(--color-primary, #3a7bd5); }
}

@layer components {
  .card { padding: 16px; background: white; border-radius: 8px; }
  .card--featured { border: 2px solid var(--color-primary, #3a7bd5); }
}

@layer utilities {
  .p-0   { padding: 0; }
  .mt-4  { margin-top: 1rem; }
  .sr-only { position: absolute; width: 1px; height: 1px; overflow: hidden; }
}

Now .p-0 overrides .card's padding — not because of specificity, but because utilities is declared after components in the layer order. No !important required.

The contract for teams

Cascade layers turn an implicit assumption ("utilities always win") into an explicit, documented contract. A new developer joining the team does not need to know the historical reason every utility class has !important — the layer order tells the whole story:

/* Layer order = priority order */
@layer reset, base, components, utilities;

New component styles go in @layer components. New utility classes go in @layer utilities. No exceptions, no special-casing, no overrides. The system enforces the convention automatically.

Unlayered rules and third-party CSS

Any CSS not assigned to a layer is implicitly placed in an "unlayered" bucket that has higher priority than any named layer. This matters when you include third-party stylesheets:

@layer reset, base, components, utilities;

/* third-party stylesheet included without @layer assignment */
@import url('third-party-modal.css');   /* goes into the unlayered bucket */

The third-party styles beat all of your named layers by default. To contain them, assign them to a layer on import:

@layer vendor {
  @import url('third-party-modal.css');
}

@layer reset, base, vendor, components, utilities;

Now vendor sits below components and utilities, and you can override it cleanly.

The revert-layer keyword

Sometimes a component in a higher layer wants to opt out of its own declaration and fall through to whatever the lower layer would have done. revert-layer makes that explicit:

@layer utilities {
  .inherit-color { color: revert-layer; }  /* falls through to @layer base value */
}

This is a sharp tool — use it when a utility genuinely needs to say "undo everything in this layer for this property", rather than setting an explicit value.

CSS resets and layers

One of the practical wins of @layer is making resets safe. A classic problem: you include a reset stylesheet that sets button { all: unset; }, but later you want to style a button and you cannot remember whether your component style or the reset wins.

Put the reset in the lowest-priority layer and the answer is always: your component styles win.

@layer reset, base, components, utilities;

@layer reset {
  /* Eric Meyer reset, Normalize, or your own — all go here */
  button { all: unset; }
}

No more mental bookkeeping. The layer order is the documentation.

Where to go next

You now have two structural tools: custom properties for values, layers for priority. Next: Design Tokens — the naming layer that sits above raw custom properties and connects the CSS system to the design tool, giving the whole team a shared vocabulary for visual decisions.