Also available in Español
The Problem
Every team inherits a stylesheet like this eventually.
Not badly written. Nobody on the original team was careless. Selectors are reasonable. Naming is consistent enough. And still, nobody touches it without dread, because nobody's sure which of its four thousand lines are load-bearing.
So the instinct is always the same. Add a new rule. Don't remove the old one — just in case. A new component gets its own selector rather than reusing something that might, somehow, be relied on elsewhere in ways nobody documented. The file grows. It never shrinks. Not because anyone decided it should only grow — because growing felt safe, and shrinking never did.
Why the Problem Exists
Removing a rule requires confidence. Adding one requires none.
That asymmetry is the whole mechanism. CSS is additive and forgiving by nature — write a new rule, and it just works, layered on top of everything that came before it, without breaking anything else in the process. That's a genuine strength. It's also exactly why nobody ever feels safe subtracting. Deleting a rule means proving nothing depends on it, across every page, every component, every browser width, every state — and CSS gives no easy way to prove that. So defensive selectors get written not because they're needed today, but because a developer isn't sure what breaks if they simply trust what's already there. Dead rules survive indefinitely, because nothing in the system ever tells anyone they're dead.
The trade-off is the same shape as the last two problems in this series, wearing a different face: the very quality that makes CSS approachable — you can always just add more — is the quality that makes large stylesheets ungovernable over time.
The First Principle
Naming it plainly: CSS has no feedback loop for irrelevance.
A compiled language flags an unused variable. An unused import gets a warning, sometimes an error. The tooling tells the author, directly, "this isn't doing anything — remove it." CSS has nothing equivalent built into the language itself. A rule that stops mattering doesn't announce itself. It just sits there, permanently ambiguous — maybe load-bearing, maybe vestigial, indistinguishable from the outside, forever.
Teams don't create this kind of entropy through carelessness. They create it because the system never tells them when it's actually safe to remove something. Given enough time and enough contributors, that silence compounds. Not through anyone's negligence — through the simple, repeated absence of a signal that never existed.
Demonstrating the Principle
A single, quiet example carries this further than a catalog would.
Somewhere in a real stylesheet: a rule targeting .legacy-card-footer. The template that used that class was rebuilt eight months ago. Nobody removed the rule, because nobody could prove, quickly, that nothing else referenced it. So it still ships. To every visitor. On every page load. Doing nothing, indefinitely, because deleting it felt riskier than leaving it — and the stylesheet itself offered no way to tell the difference.
quell as the Case Study
Explicit layer boundaries don't make dead code impossible. They make it findable. A stale rule sitting inside components is a much smaller, more searchable problem than a stale rule buried somewhere in one undifferentiated global file with no boundary telling you where to even start looking.
The Broader Lesson
Entropy isn't a discipline failure. Not in CSS, not anywhere else.
It's what happens, reliably, whenever a system rewards addition and offers nothing in return for subtraction. The fix was never "try harder to remove things" — that's the same discipline-as-solution instinct this series has already set aside twice. The fix is building a system where removal is exactly as safe, and exactly as visible, as addition always was.
That's the thread running under all three articles so far. Not a series of unrelated CSS complaints — one recurring shape, worn differently each time: a system with no architecture will eventually ask discipline to do a job discipline was never built for.
Top comments (0)