CSS @layer: How Cascade Layers End the Specificity War

You have a card component from a design-system library: .card .card__header .card__title { font-size: 18px; } — three classes in the selector, because that's how the component's author nested it. You want to override it with a single utility class, .text-lg { font-size: 20px; }, added in the HTML after the card's classes. It doesn't work. The title stubbornly stays at 18px, even though .text-lg appears later in the code, so intuitively "the newer one should win." That's not a browser bug — three classes in a selector beat one class, regardless of order in the file. That's how specificity has worked since 1996, and that's how it's supposed to work.

The classic workaround is boosting your own rule's specificity — .card .text-lg, or, if that's not enough, !important. Both solutions work locally and break down systemically: every time someone on the team adds a rule with even higher specificity (or one more !important), the rest of the stylesheet becomes unpredictable. That's exactly the problem — not an aesthetic one, an architectural one — that CSS Cascade Layers solve.

A new axis for resolving conflicts, not another way to boost priority

The key thing to understand: @layer isn't yet another tool for raising a rule's priority, the way !important or tacking on another class to a selector is. It's a separate stage of the cascade algorithm, resolved before specificity, not alongside it. The full order in which the browser resolves a conflict between two CSS rules looks (simplifying by leaving out origin) like this:

1. Layer (@layer) – a rule from a layer declared later wins over a rule from a layer declared earlier, regardless of the specificity of the selectors inside them.
2. Specificity – only resolves things once both rules are in the same layer (or neither is in any layer at all).
3. Source order – the final tiebreaker, when the previous two criteria come out even.

That means a single .text-lg class in a later layer can beat a three-class-deep selector in an earlier layer — because the clash never even reaches the point of comparing specificity. The layer settles it first.

css

/* You declare layer order once, up front – it doesn't need to match
 the order in which their content actually appears in your files */
@layer reset, base, components, utilities;

@layer components {
.card .card__header .card__title {
  font-size: 18px;
}
}

@layer utilities {
.text-lg {
  font-size: 20px;
}
}

That empty declaration, @layer reset, base, components, utilities;, at the top of the file isn't a formality — it's an explicit statement of priority order, made before any of these layers get any real content. Because of it, layer order is independent of import order or file order — components can physically appear in the code before utilities, and utilities will still win, because that's the order declared at the start.

A practical example: reset, components, and utilities that never fight each other

In practice, this pattern — reset below components, components below utility classes — is exactly how the layer system in Tailwind has worked since version 3.1: a utility class is always meant to win over a component rule, no matter how many classes that component's selector has, because that's precisely why utility classes exist in the first place.

css

@layer reset, base, components, utilities;

@layer reset {
* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}
}

@layer base {
body {
  font-family: system-ui, sans-serif;
  color: #1a1a1a;
}
}

@layer components {
.card {
  border: 1px solid #e0e0e0;
  border-radius: 12px;
  padding: 16px;
}

.card .card__header .card__title {
  font-size: 18px;
  font-weight: 600;
}
}

@layer utilities {
.text-lg {
  font-size: 20px !important;
}

.mt-4 {
  margin-top: 16px;
}
}

Notice that the !important on .text-lg inside the utilities layer is unnecessary here — the layer already guarantees priority, without needing to reach for CSS's heaviest weapon. That's a good illustration of why cascade layers genuinely reduce the amount of !important in your code: you stop needing it as a workaround for specificity, because you now have a tool designed exactly for this job.

The same mechanism solves a second, equally common problem — a third-party CSS library whose selectors you don't control, and whose priority you always want lower than your own styles, without boosting the specificity of your own rules:

css

@import url("some-ui-library.css") layer(vendor);

@layer vendor, base, components, utilities;

The entire library lands in the vendor layer, placed at the very start of the order — so your base, components, and utilities will always beat it, no matter how aggressively that library builds its selectors.

A pitfall that breaks intuition: unlayered styles beat every layer

This is the most commonly overlooked, and simultaneously the most consequential, detail of the whole mechanism: a rule that isn't in any layer at all wins over a rule in any layer — for ordinary, non-!important declarations. It doesn't "lose because it's in some invisible layer at the end" — it wins, always, unconditionally, against every layered rule, even if that rule sits in a layer declared as the highest priority.

css

@layer utilities {
.text-lg {
  font-size: 20px;
}
}

/* This rule, even though it's in no layer and looks like a random,
 one-off override – WINS over .text-lg above, no matter
 where in the file it sits */
.title {
font-size: 16px;
}

This behavior is deliberate — it's what makes gradually rolling out cascade layers in an existing, large project safe: all the "old" CSS that hasn't been moved into any layer yet keeps its highest priority by default, so it doesn't suddenly start losing to newly added layers. But that same behavior is the source of the most confusing bugs in teams that adopt @layer only partially: a single rule accidentally left outside any layer — a typo, a forgotten import, a <style> block injected by a third-party library — will beat your carefully designed priority system, with no warning at all. The practical consequence: if you commit to cascade layers, consistently put everything into some layer, including the reset and base styles — don't leave a single rule "outside," because that rule, not your utilities layer, is what wins every conflict.

A second pitfall: !important reverses layer order

If you reach for !important inside a layer, the priority order between layers reverses. For ordinary declarations, the layer declared later wins. For declarations with !important, the layer declared earlier wins.

css

@layer reset, components;

@layer reset {
.card { padding: 0 !important; }
}

@layer components {
.card { padding: 16px !important; }
}
/* reset wins (0px), because with !important priority goes to the
 layer declared earlier – the exact reverse of the rule
 that applies without !important */

This isn't a quirk of the spec — it's a consistent extension of a rule that already existed for origins (user stylesheet !important has always beaten author-stylesheet !important, the opposite of what happens with regular declarations). The practical takeaway: !important inside a layer system can catch out even someone who understands regular @layer ordering perfectly well — one more good reason to treat !important as something you reach for deliberately and rarely, not as your default way of winning a fight.

Pitfalls and best practices

• Zero rules outside layers, if you want the system to be predictable. As shown above, even a single rule without @layer beats the whole layer system for ordinary declarations — consistency matters more than the convenience of dropping in "just one small rule" on the fly.
• Specificity still applies inside a single layer. @layer eliminates specificity wars between layers, but inside one layer, two rules still resolve conflicts the same way they always have — sensible class naming and avoiding deeply nested selectors still pays off.
• Declare layer order explicitly, right at the top, with an empty @layer name1, name2, ...;. This removes your dependency on file import order — priority order gets established once, clearly, in one place, no matter what order the individual CSS files actually load in later.
• Browser support is no longer a reason for caution. Cascade Layers reached Baseline (widely available) status back in 2022 — Chrome 99, Firefox 97, Safari 15.4 — so you can adopt them without @supports in any new project.

Conclusion

@layer doesn't compete with specificity — it operates at an entirely different stage of the cascade algorithm, earlier, and that's what lets a single utility class deliberately and predictably beat a selector with three nested classes, without boosting priority and without !important. It's a genuine architectural tool for splitting reset, base styles, components, and utilities into layers with an explicitly declared order of importance — but two of its rules break intuition sharply enough to be worth memorizing on their own: a style outside any layer beats every layer, and !important inside layers reverses their priority order. Ignoring either of these two facts won't end in a console error — it'll end in CSS that behaves differently from what the seemingly logical layer order in the file would suggest.