DEV Community

Franklin
Franklin

Posted on

Why Zero Specificity Changes Everything

Also available in Español

The Problem

A base style gets written to be quiet. Something meant to set a sensible default and then get out of the way the moment anything more specific shows up to override it.

It doesn't get out of the way. A component's own styling, written later, with what looks like a perfectly reasonable selector, loses to it anyway. The developer who wrote the base style never wanted it to win. It won regardless, because nothing in how it was written ever declared "I should always lose."

Why the Problem Exists

Most selectors accumulate specificity as a side effect of how they happen to be written, not as a deliberate choice anyone made on purpose. :is() is a good example of this in practice: genuinely useful for grouping several selectors into one rule, but it quietly takes on the specificity of its most specific argument. A selector reached for out of convenience can become a heavyweight one without anyone intending that outcome.

Nothing in ordinary CSS lets an author say, directly, "group these together, but keep the result at zero." So defaults quietly become more powerful than they were meant to be, and the same override problems named earlier in this series resurface here in a new shape not because anyone was careless, but because specificity was accumulating as a byproduct instead of being declared as a decision.

The First Principle

Specificity of zero isn't an absence of power. It's a declared intention: this rule should always be the easiest thing in the codebase to override.

That's not a weaker rule. It's a rule with a stated, permanent role the same "declared, not calculated" idea from earlier in this phase, now living inside a single selector instead of an entire ordering system. Choosing zero specificity on purpose turns out to be a more sophisticated move than carefully managing specificity upward ever was.

Demonstrating the Principle

:is(h1, h2, h3) { margin-block: 0; }
Enter fullscreen mode Exit fullscreen mode

Picks up real specificity from its arguments this rule can still fight a class selector and, depending on what else is nested inside, sometimes win when it shouldn't.

:where(h1, h2, h3) { margin-block: 0; }
Enter fullscreen mode Exit fullscreen mode

:where() Contributes zero specificity, regardless of what's grouped inside it. A single class beats this every time, by design — not because the selector is weak, but because it was written to always lose on purpose.

quell as the Case Study

quell uses :where() throughout its base layer specifically so nothing meant to be a quiet default can ever accidentally out-rank something meant to override it.

The Broader Lesson

Phase Two closes here, and it's worth naming what's been true across all four of these articles. Layers. The full resolution order. Deliberate exclusions. Now zero specificity. Every one of them has the same shape underneath: precedence, scope, and power are strongest when they're declared on purpose, not left to accumulate as a side effect of how something happened to get written.

That's the whole shift this phase has been making, one mechanism at a time: from a cascade people managed defensively, rule by rule, to a cascade people can actually design against, on purpose, in advance.

Top comments (0)