W

r

i

t

e

M

o

r

e

P

r

e

d

i

c

t

a

b

l

e

C

S

S

U

s

i

n

g

@

l

a

y

e

r

s

At its core, CSS has always relied on a few things to determine which style wins when multiple rules apply: source order, specificity, and importance (!important). This system works, but it breaks down as projects scale.

CSS Layers introduce a new axis to the cascade: @layer. You can now explicitly control the order of entire groups of styles, regardless of specificity or order in your stylesheet.

Think of it like stacking boxes:

• Each layer is a box.
• CSS rules inside the top box win over those in boxes below, even if they have lower specificity.

This makes styles more predictable, especially in large codebases or design systems.

If you’re working with component libraries, design tokens, or CSS-in-JS tools in a React project, layering lets you define things like:

• Base styles (tokens, resets) that never override your app styles.
• Theme styles that can override base styles but not your app-specific overrides.
• Component styles that sit in their own sandbox.

This structure reduces bugs and mental overhead.

Let’s walk through a step-by-step example of how you might structure layers in a real React project using plain CSS Modules or even global styles.

Define Layers

This line sets up named layers and their explicit order from bottom (least priority) to top (most priority).

So:

reset < base < components < utilities < overrides

Add Styles to Layers

Now, we assign styles to those layers.

Even though .button appears in both the components and overrides layers, the one in overrides wins, without needing to increase specificity or use !important. Yay

Using It in React App

Let’s say you’re using create-react-app, Vite, or Next.js. You can add a global stylesheet that imports these layers, or even better, split each layer into its own file:

In your root layout:

And Boom! You’ve just created a clean, maintainable style architecture.

Imagine you’re working on a design system for a pet adoption app. You’ve got tokens for spacing, typography, and colours. Then you’ve got buttons and card components. Finally, you want consumers of your system to override styles without fighting your specificity.

This is a perfect use case for cascade layers:

In practice it would look something like the example below:

import React from "react";
import "./styles.css";
import Button from "./Button";


export default function App() {
return (
<div className="app">
<h1>Design System Layering</h1>
<Button>Adopt a Dog 🐶</Button>
</div>
);
}

You get the power of theming without leaking specificity.

It’s always a good to define your layer order early on using @layer name1, name2, ... by grouping related styles together in named layers. To make things more modular, use @import with the layer() keyword.

Bu remember @layer won’t fix fix bad CSS structure. It’s a tool, not a silver bullet.

CSS Layers are like adding TypeScript types to your stylesheets: more structure, more predictability, less pain in the long run. For frontend engineers building complex UIs with React and design systems, they offer a powerful way to bring order to your CSS without relying on naming conventions and more !importantly, no specificity hacks.

So next time your component styles are fighting with a global reset or a rogue utility class, think @layers.

As always, halpy coding