Also available in Español
The Problem
Every new project starts the same way.
A reset goes in first. Eric Meyer's, normalize.css, one of the modern reset gists passed around in a team's starter template - it doesn't matter which. It happens before the first component, before the first token, before anyone has made a single real decision about how the site should look.
It feels like housekeeping. Not a decision. Just clearing the ground before the real work starts.
But some of what's in that file isn't clearing anything. It's deciding.
A reset genuinely fixes real inconsistency - browsers used to disagree, sometimes still do, on small structural defaults. That part is legitimate. But most resets don't stop there. They also strip list markers globally. They flatten heading sizes down to nothing. They remove default spacing that was never actually inconsistent between browsers, just present. Somewhere in that file, "fixing a disagreement" quietly became "encoding a preference" — and nobody voted on the preference. It arrived bundled with the fix, wearing the same label.
Why the Problem Exists
Browsers used to disagree more than they do now. Margin on <body>. List indentation. Form control appearance. Early resets existed to paper over that - a real, narrow, worthwhile job.
But "zero everything out" is a much easier template to write than "fix only what's actually inconsistent." So that's what most resets became: blanket removal, applied uniformly, regardless of whether a given default was ever the source of disagreement in the first place. Once nuking everything became normal, opinion rode along for free. Box-sizing choices. Heading scale flattening. List-style removal on every list, including the ones that are semantically lists and should probably look like lists.
Nobody separated "this fixes a bug" from "this reflects a preference" - because the file never asked them to. The trade-off is real: resets buy consistency across browsers, and they buy it by quietly encoding undocumented design decisions as though those decisions were neutral defaults nobody chose.
The First Principle
There are two different jobs hiding inside every reset file, and they're not the same job.
Normalization is narrow: browsers disagree about the same intended behavior, so the disagreement gets fixed. That's it. No taste involved - just alignment.
Baseline opinion is something else entirely: deciding what unstyled content should look like. That's a design act. It's not wrong to make that decision - every project needs one - but it's a different kind of decision than fixing a browser disagreement, and it deserves to be made on purpose, not smuggled in under the same file header.
A browser's own UA stylesheet is worth a quick look here - the default styling every browser ships before any author CSS runs at all. It's more consistent across modern engines than most developers assume, and that single fact quietly undercuts the premise that justifies nuking everything: if the defaults were really as chaotic as the reset ritual implies, this document wouldn't read as boring and cross-browser-consistent as it does.
Demonstrating the Principle
Something like form control font inheritance is a fair candidate for normalization - historically, some browsers didn't inherit font styling into buttons and inputs the way authors expected, which is a genuine cross-browser disagreement worth fixing once, deliberately.
/* 1. Normalization */
button, input, select, textarea {
font-family: inherit;
}
/* 2. Opinion */
ul, ol {
list-style: none;
}
Compare that to a line nearly every reset includes without comment: stripping list-style from every <ul> and <ol> on the page. That isn't fixing a disagreement between browsers - every browser agrees on what a list should look like by default. It's a design decision, made on the reader's behalf, before the reader ever opened a stylesheet. Nothing wrong with wanting unstyled lists. Something wrong with that preference arriving disguised as a fix.
quell as the Case Study
quell keeps these two jobs in separate places rather than one undifferentiated file. Normalization lives in quell-base - narrow, boring, cross-browser corrections only. Anything opinionated lives elsewhere, declared as what it is. Nothing in the system gets to claim neutrality it hasn't earned.
The Broader Lesson
The mistake was never using a reset. The mistake was treating "reset" as one homogeneous category of file, instead of two different jobs that happen to usually ship bundled together.
That pattern isn't unique to CSS. Any time a tool bundles a fix and an opinion into a single undifferentiated step, the opinion stops looking like a choice. It starts looking like a default - something nobody has to justify, because it arrived before anyone was asked.
Worth asking, the next time a reset goes into a new project: which lines are fixing something real, and which ones are just someone's taste, wearing a fix's clothing.
Top comments (0)