Frameworks Didn't Solve CSS. They Avoided It.

Also available in Español

The Problem

"We don't have CSS problems, we use Tailwind." "Bootstrap handles that for us." Some version of that sentence gets said on nearly every team that's adopted a framework, and it's usually said with real relief.

It's also not quite true. Frameworks solved real problems. The cascade was never one of them.

Why the Problem Exists

Frameworks were built to fix things that genuinely needed fixing: inconsistent component markup across a team, the tedium of hand-rolling the same button and card patterns for the tenth time, and a real tooling gap around build steps, purging unused styles, and distributing design tokens at scale. Solving those was worth serious engineering effort, and frameworks earned their adoption honestly by solving them well.

None of that effort touched origin, layer order, specificity, or source order. The resolution sequence this series spent its second phase explaining kept operating exactly as it always had, underneath the framework's classes instead of an author's own. A team could adopt the most disciplined component library available and still inherit every override war, every accidentally-too-specific base style, every unpredictable interaction this series has spent eight articles diagnosing. The framework changed what got written. It never touched how the browser decides which of it wins.

The First Principle

Composition and reuse are authoring-time problems: how convenient is it to build UI. The cascade is a resolution-time problem: how the browser decides what wins when rules conflict.

Those are two different layers of the same system, solved by two different kinds of engineering. A framework can make authoring dramatically better while leaving resolution exactly as unpredictable as it was, because making one layer better was never going to touch the other. That's not a flaw in what frameworks set out to do. It's a category they were never aimed at in the first place.

Demonstrating the Principle

.btn { padding: 0.5rem 1rem; }
.btn-primary { background: blue; }

Two framework-style classes, applied together to the same button. Which wins if they ever conflict on the same property isn't decided by anything the framework introduced — it still comes down to source order and specificity, resolved by the exact sequence from earlier in this series. The vocabulary changed. The mechanism deciding the outcome didn't.

quell as the Case Study

quell exists to address that resolution layer directly, rather than offering convenience on top of a cascade left unresolved underneath it.

The Broader Lesson

This is a familiar shape outside CSS too: a real, valuable solution to one problem gets mistaken for a solution to a different, adjacent problem, because the two showed up bundled together in the same tool. The bundling wasn't dishonest. It just meant one problem got solved loudly enough that the other one went quiet without actually going away.

Composition tools and architectural guarantees aren't the same category of thing. The next two articles draw that line more precisely.