Also available in Español
The Problem
Ask most developers to explain specificity, and they can. Ask about inheritance, and they can explain that too. Source order, origin, !important — most of these get learned individually, usually while debugging something that broke, usually forgotten again once the immediate fire is out.
Almost nobody learns them as one system.
Here's the reframe that actually matters: the browser doesn't have six unrelated CSS facts scattered around its rendering engine. It has a complete, specified cascade resolution algorithm, an actual, ordered answer to "which rule applies here," worked out stage by stage. Most projects have never read that algorithm end to end. They've only ever met it one broken layout at a time.
Why the Problem Exists
These mechanisms get taught piecemeal, because that's how they get needed. A tutorial explains specificity because specificity is the thing that just bit someone. A Stack Overflow answer explains inheritance because someone's font size wasn't behaving. Each explanation is accurate, narrow, and disconnected from the five other stages of the same algorithm sitting right next to it.
That's an efficient way to patch one bug. It's a poor way to learn a system. A team can understand specificity in real depth and still not realize that origin, importance, and layer order all get resolved before specificity is ever consulted — which means hours can be spent fighting a specificity battle that was already lost, or won, at an earlier stage nobody thought to check. When that happens enough times, teams stop trusting the cascade at all. They build a parallel architecture on top of it instead — naming conventions, scoped tooling, extra layers of abstraction — to solve problems the browser's own algorithm already resolves, just not visibly, because nobody read the whole thing as one sequence.
The First Principle
Here's the actual order, laid out as a sequence rather than a glossary of separate terms.
Origin and importance are checked first: browser styles, author styles, user styles, and whether !important is attached to any of them. Then layer order, for anything declared inside @layer — though worth knowing, !important flips that order, so the first declared layer wins instead of the last. Then specificity, but only among rules that have already survived the first two stages unresolved. Then source order, as the final tiebreaker when nothing else has settled it. Inheritance runs underneath the entire sequence, quietly supplying an answer for any property none of the above ever addressed.
The reframe: this was never six facts to memorize separately. It's one ordered algorithm, and each of those familiar words (origin, layers, specificity, source order, inheritance) names a single stage inside it. Learned in isolation, they're trivia. Learned as a sequence, they're an engineering contract a team can design against on purpose.
Demonstrating the Principle
A layered rule with high specificity can still lose to an unlayered rule with far less specificity and that's not a bug, it's the sequence working as specified. Layer order is resolved before specificity is ever reached. For normal styles, unlayered rules sit above all explicit layers in precedence, winning over layered rules regardless of specificity. For !important styles, that priority flips, giving layered rules the advantage. Knowing where layers sit in the sequence relative to origin and importance is the difference between an unexpected override and a predictable design system.
quell as the Case Study
quell's architecture holds up reliably in production for a plain reason: it was designed with this full resolution order in view from the start, not assembled by trial and error against isolated rules learned one at a time.
The Broader Lesson
Most engineering problems that feel like missing features are actually missing understanding of a system that was already provided. The browser didn't fail to give CSS an architecture. It gave one, fully specified, stable, standards-track, and most projects quietly build a second, informal one on top of it, because the first one was never read as a whole.
That pattern isn't unique to CSS. It shows up anywhere a system gets learned in disconnected pieces instead of as the single sequence it actually is: reinventing what's already there, at real cost, because nobody ever sat down and read the whole thing end to end.
Top comments (0)