Thinking Horizontally in CSS @layer – Master.dev Blog
/ BLOG
@layerComponentsCSSCustom PropertiesDesign
Thinking Horizontally in CSS @layer
Chris Coyier<br>on<br>July 9, 2026
I joked the other day:
wait is @layer like z-index but for CSS itself<br>— Chris Coyier (@chriscoyier.net) 2026-06-26T04:04:38.605Z
I know what CSS @layer is, and maybe you do too. This won’t be a reiteration of the rhyme and reason of the feature itself. For that, you probably can’t do better than Miriam’s guide. Rather, this will be about a different way of thinking about layers that might be useful to you.
The point of my lame observational joke is that we tend to think of CSS @layer as a vertical concern. This is true of so many other CSS concepts. Like inline styles are above styles applied in a stylesheet. Your user-authored styles are above the user-agent styles that browsers ship and apply to all pages. But the main thing we think about is specificity. IDs are stronger than classes are stronger than elements, and all that.
Along comes @layer and it can make us think even more vertically. Now, we essentially "stack" layers. Styles in a higher layer are more powerful (regardless of specificity) than styles in a lower layer. So our code can literally be structured like this, which is also a vertical stack.
Strength defaults unless we medle with them with a name-only @layer statement.
You can also be specific about layering them.
@layer reset, defaults, patterns, components, utilities, overrides;Code language: CSS (css)
I like that, myself, as it freaks me out a little bit that otherwise each @layer is stacked through source order alone.
There is another little bit of syntax that I find interesting: sub-layers. You use a dot/period for this, like:
@layer components.button {
@layer components.card {
@layer components.grid {
}Code language: CSS (css)
So now all these layers are still slotted into the power hierarchy, where the components is, but then have their own sub-heirarchy, which would be source-order, unless we force it ourselves like:
@layer<br>reset,<br>defaults,<br>components,<br>components.button,<br>components.card,<br>components.grid,<br>patterns,<br>...;Code language: CSS (css)
The Thing About Components: There Are Many
Maybe you have like 50? 100? 374?
And if you’re like me (and a lot of front-end architectures!), you like the one-CSS-file-per-component setup (sometimes like this).
With this many components and many CSS files, the point is: who cares about the vertical ordering of the layers? It just doesn’t matter which component’s styles beat another component’s styles.
So you can either just not name them:
/* components/button/button.css */<br>@layer components {<br>.button {<br>/* button styles */<br>}Code language: CSS (css)
/* components/card/card.css */<br>@layer components {<br>.card {<br>/* card styles */<br>}Code language: CSS (css)
Or do name them (just "in case"), but don’t even bother to order them specifically, because it probably doesn’t matter.
/* components/button/button.css */<br>@layer components.button {<br>.button {<br>/* button styles */<br>}Code language: CSS (css)
/* components/card/card.css */<br>@layer components.card {<br>.card {<br>/* card styles */<br>}Code language: CSS (css)
A Component Might Have Layered and Unlayered Styles
You can already get some level of CSS scoping to a component, even without any fancy tools. Say you have a Card component (as we’ve been using an example), it could just have that class of Card, and you nest everything beneath that, and that’s that.
.card {<br>.title {<br>.meta {<br>/* etc. */<br>}Code language: CSS (css)
Or perhaps you have some naming convention like BEM or whatever.
Maybe you get even fancier and use @scope like:
@scope (.card) {
/* or you have a custom element */<br>@scope (design-system-card) {
}Code language: CSS (css)
You could even use a name-only container query, which I find kind of satisfying for some reason.
/* Name a container */<br>.card {<br>container-name: ds-card;<br>container-type: inline-size;
/* Write styles with that name only, no conditions */<br>@container ds-card {<br>.title {<br>/* classes like me won't "leak out" */<br>.meta {<br>/* etc. */<br>}Code language: CSS (css)
Literally any of that will work with what I’m about to show.
The idea is that you layer the tokens the component uses, and you don’t layer scoped stuff.
@layer components.card {<br>/* intentionally weakened so any other selector can override values */<br>.card {<br>--card-bg: black;<br>--card-color: white;<br>/* etc. */
/* Scope for protection while retaining some strength */<br>@scope (.card) {<br>background: var(--card-bg);<br>color: var(--card-color);<br>}Code language: CSS (css)
The Point is Intentionally Weak Tokens
I don’t want to have to fight to override tokens. That should be really easy. I don’t want to think about source order or if the selector I’m using is strong enough to do the job. In the code block above, because I’ve used @layer to wrap where I’m setting the tokens, any higher layer, and definitely unlayered CSS, can target the card and...