CSS Cascade Layers: Finally Tame Your Specificity Wars

CSS Cascade Layers (the @layer rule) let you group style rules into named layers with an explicit priority order, so a low-specificity selector in a later layer beats a high-specificity selector in an earlier one. This removes the need for !important chains or selector-weight arms races between resets, frameworks, and component styles.

What Problem Are Cascade Layers Actually Solving?

Before layers, the cascade resolved conflicts using origin, specificity, and source order, in that priority. Specificity was the part developers fought with most. A .card .title rule from your design system could silently outrank a header h2 you wrote three files later, forcing you to either raise your own specificity or reach for !important. Neither is fun to maintain, and both make future overrides harder, not easier.

Layers add a new axis to the cascade that sits above specificity. If rule A is in an earlier layer and rule B is in a later layer, B wins regardless of how specific A's selector is. Specificity still matters, but only for resolving conflicts within the same layer. This is the same mental model as CSS-in-JS libraries or BEM naming conventions tried to simulate through convention. Layers do it natively, and the browser enforces it.

The practical result: you can load a third-party library's CSS, a reset, your base styles, and your component overrides, declare their order once, and never worry about whose selector "weighs more."

Basic Syntax and Layer Ordering

You declare layers with @layer, either inline with a block of rules or as a bare statement that just registers the order.

1/* Register layer order up front, before any rules exist.
2 This is the recommended pattern: it makes the priority
3 explicit and independent of where each layer's styles
4 actually get authored later in the file or in imports. */
5@layer reset, base, components, utilities;
6
7@layer reset {
8 * {
9 margin: 0;
10 padding: 0;
11 box-sizing: border-box;
12 }
13}
14
15@layer base {
16 body {
17 font-family: system-ui, sans-serif;
18 line-height: 1.5;
19 }
20}
21
22@layer components {
23 /* Even a very specific selector here loses to anything
24 in the "utilities" layer below, because layer order
25 outranks specificity. */
26 .card .card__title {
27 font-size: 1.25rem;
28 color: #222;
29 }
30}
31
32@layer utilities {
33 /* A single class, but it wins because "utilities" is
34 the last-declared layer. */
35 .text-brand {
36 color: var(--brand-color);
37 }
38}

Layer order is determined by first declaration, not by where the rules physically live in the file. If you register reset, base, components, utilities at the top, that order is locked in for the whole cascade, even if later @layer blocks appear in a different sequence further down the stylesheet.

One detail that catches people off guard: unlayered styles (plain CSS not wrapped in any @layer) are treated as if they belong to an implicit final layer that comes after every named layer. That means a stray .text-brand { color: red; } sitting outside any layer will beat everything above, including your utilities layer. This is by design per the CSS Cascade Layers specification, but it surprises teams migrating an existing codebase incrementally, since old, un-layered rules suddenly outrank the new layered system.

How Do Layers Interact With Third-Party CSS?

This is where layers earn their keep. Say you import Bootstrap or Tailwind's preflight, plus your own component library, plus a few utility overrides. Historically you'd fight selector specificity or resort to !important to make your overrides stick.

1/* Import third-party CSS directly into a named layer.
2 Anything Bootstrap ships, no matter how specific,
3 now lives entirely inside the "vendor" layer. */
4@import url("bootstrap.css") layer(vendor);
5
6@layer vendor, base, components, overrides;
7
8@layer overrides {
9 /* This single class selector now safely beats every
10 Bootstrap rule, including deeply nested ones like
11 .navbar .nav-link.active, without !important. */
12 .nav-link {
13 color: var(--brand-accent);
14 }
15}

The @import ... layer(name) syntax assigns an entire imported stylesheet to one layer in a single line. This is arguably the single most useful pattern for teams maintaining design systems on top of vendor CSS, because it turns "vendor CSS always wins on specificity" from a permanent headache into a one-time layer assignment. See the MDN reference on @import for the full syntax including media queries combined with layers.

You can also nest layers (@layer components.buttons), which is useful for larger design systems that want sub-ordering within a category without polluting the top-level layer list. Nested layer names are dot-separated and each level of the hierarchy resolves independently.

Where Do !important and Layers Collide?

Here's the part that trips up even people who think they understand layers: !important inverts the layer order for the declarations it touches. A !important rule in an earlier layer beats a normal (non-important) rule in a later layer, and beats other !important rules in later layers too... except the priority among competing !important declarations across layers is reversed compared to normal declarations.

1@layer base, override;
2
3@layer base {
4 /* !important flips this rule to win over the
5 override layer below, even though "override"
6 is declared later and would normally take priority. */
7 p {
8 color: blue !important;
9 }
10}
11
12@layer override {
13 p {
14 color: red;
15 }
16}
17/* Result: paragraphs render blue, not red. */

This inversion is intentional per spec, meant to preserve !important's original purpose as an emergency override mechanism regardless of layering, but it means you cannot reason about !important in a layered stylesheet the same way you reason about it in a flat one. My advice from working with layers in production: treat !important and cascade layers as mutually exclusive tools. If you've adopted layers to get away from specificity hacks, don't reintroduce !important into the mix, or you will end up debugging cascade order twice, once for layers and once for the inversion.

Browser Support and Migration Caveats

Cascade Layers reached broad support faster than many CSS features. Chrome and Edge supported @layer starting with version 99 (March 2022), Firefox followed in version 97 (also March 2022), and Safari shipped it in Safari 15.4 (March 2022). As of 2026 every actively maintained browser supports the feature, and you can treat it as safe for production use without a fallback in the vast majority of projects. Check current numbers on caniuse before committing if your analytics show meaningful traffic from legacy browser versions or older WebViews, since some embedded WebView contexts on older Android OEM builds lag behind the underlying Chrome version.

The bigger practical risk isn't support, it's migration order. If you retrofit layers onto an existing large stylesheet, any CSS you haven't yet wrapped in a layer becomes part of that implicit final layer mentioned earlier, and will outrank your new layered code. Teams migrating incrementally often wrap legacy CSS in a @layer legacy block explicitly and place it first in the order, rather than leaving it unlayered, specifically to avoid this trap.

Another edge case worth knowing: layers apply per stylesheet scope but the ordering is global across the document once declared. If two separate stylesheets both declare @layer utilities without agreeing on where it sits relative to other layers, whichever declaration order the browser encounters first wins for that layer's position, and later re-declarations of the same layer name just add rules to the existing layer, they don't move it. This matters for teams shipping CSS via multiple build outputs or micro-frontends where load order isn't guaranteed. Consolidate your top-level @layer order declaration into one shared entry point if you can, rather than letting each bundle declare its own guess at where it belongs.

Testing Your Layer Order in DevTools

Chrome DevTools and Firefox's inspector both show layer membership in the Styles panel: hover over a rule and you'll see its layer name listed above the selector, along with a visual indicator of cascade priority. This is the fastest way to confirm your mental model matches reality, especially after adding a third-party import. Open the inspector on an element you expect to be overridden, check which layer the winning rule belongs to, and if it's not the layer you expected, check your top-level @layer statement for typos or ordering mistakes first, since a misspelled layer name silently creates a new layer rather than throwing an error.

If you're deciding whether to adopt layers on an existing project versus a greenfield one, greenfield is the easier call: declare your layer order on day one and every contributor inherits the discipline. On an existing codebase, budget time for the legacy-layer wrapping step described above, because skipping it is the single most common cause of "I added layers and now my overrides don't work" bug reports.