DEV Community: Franklin

La mayoría de los CSS resets resuelven el problema equivocado

Franklin — Tue, 04 Aug 2026 11:16:21 +0000

También disponible en English.

El problema

Cada proyecto nuevo comienza igual.

Primero va el reset. Ya sea el de Eric Meyer, normalize.css o alguno de los gists modernos que circulan en la plantilla de inicio de un equipo; no importa cuál. Sucede antes del primer componente, antes del primer token, antes de que alguien haya tomado una sola decisión real sobre la estética del sitio.

Se siente como limpieza. No como una decisión. Solo despejar el terreno antes de que comience el trabajo real.

Pero parte de lo que contiene ese archivo no despeja nada. Está decidiendo.

Un reset soluciona inconsistencias reales de forma genuina; los navegadores solían diferir, y a veces todavía lo hacen, en pequeños valores estructurales por defecto. Esa parte es legítima. Pero la mayoría de los resets no se detienen ahí. También eliminan los marcadores de lista globalmente. Reducen el tamaño de los encabezados hasta desaparecer. Eliminan espaciados por defecto que nunca fueron inconsistentes entre navegadores, simplemente estaban ahí. En algún punto de ese archivo, "solucionar un desacuerdo" se convirtió silenciosamente en "codificar una preferencia" - y nadie votó por esa preferencia. Llegó empaquetada con la solución, bajo la misma etiqueta

Por qué existe el problema

Los navegadores solían discrepar más que ahora. El margen en el <body>. La sangría de las listas. La apariencia de los controles de formulario. Los primeros resets existieron para cubrir eso: un trabajo real, estrecho y valioso.
Pero "poner todo a cero" es una plantilla mucho más fácil de escribir que "arreglar solo lo que es inconsistente".

Así que en eso se convirtieron la mayoría de los resets: una eliminación masiva, aplicada uniformemente, sin importar si un valor por defecto fue alguna vez fuente de desacuerdo. Una vez que arrasar con todo se volvió normal, la opinión se coló gratis. Elecciones de box-sizing. Aplanamiento de la escala de encabezados. Eliminación del estilo de lista en cada lista, incluso en aquellas que son semánticamente listas y probablemente deberían verse como tales.

Nadie separó "esto arregla un error" de "esto refleja una preferencia", porque el archivo nunca pidió hacerlo. El intercambio es real: los resets compran consistencia entre navegadores, y la compran codificando silenciosamente decisiones de diseño no documentadas como si fueran valores neutrales que nadie eligió.

El primer principio

Normalización es un concepto estrecho: los navegadores discrepan sobre un mismo comportamiento intencionado, por lo que el desacuerdo se soluciona. Eso es todo. No hay gusto de por medio, solo alineación.

Opinión de base es algo totalmente distinto: decidir cómo debería verse el contenido sin estilos. Es un acto de diseño. No está mal tomar esa decisión - cada proyecto necesita una - pero es un tipo de decisión diferente a solucionar un desacuerdo de navegador, y merece ser tomada a propósito, no introducida de contrabando bajo el mismo encabezado de archivo. Vale la pena echar un vistazo a la hoja de estilos de agente de usuario (UA) de un navegador: el estilo por defecto que cada navegador incluye antes de que se ejecute cualquier CSS de autor

Es más consistente entre los motores modernos de lo que la mayoría de los desarrolladores asumen. Ese simple hecho debilita silenciosamente la premisa que justifica arrasar con todo: si los valores por defecto fueran realmente tan caóticos como implica el ritual del reset, este documento no se leería de forma tan aburrida y consistente entre navegadores como lo hace.

Demostración del principio

Algo como la herencia de fuente en los controles de formulario es un buen candidato para la normalización. Históricamente, algunos navegadores no heredaban el estilo de fuente en botones e inputs como los autores esperaban; ese es un desacuerdo genuino que vale la pena arreglar una vez, deliberadamente.

/* 1. Normalización */
button, input, select, textarea {
  font-family: inherit; 
}

/* 2. Opinión */
ul, ol {
  list-style: none; 
}

Compara eso con una línea que casi cada reset incluye sin comentar: eliminar el list-style de cada <ul> y <ol> en la página. Compara eso con una línea que casi cada reset incluye sin comentar: eliminar el list-style de cada <ul> y <ol> en la página. No hay nada malo en querer listas sin estilo. Hay algo malo en que esa preferencia llegue disfrazada de solución.

quell como estudio de caso

quell mantiene estas dos tareas en lugares distintos en vez de en un solo archivo indiferenciado. La normalización vive en quell-base: correcciones estrechas, aburridas y exclusivamente para la consistencia entre navegadores. Cualquier cosa con opinión vive en otro lugar, declarada como lo que es. Nada en el sistema puede reclamar una neutralidad que no se ha ganado.

La lección general

El error nunca fue usar un reset. El error fue tratar al «reset» como una categoría homogénea de archivo, en lugar de dos tareas diferentes que suelen enviarse empaquetadas. Ese patrón no es exclusivo de CSS. Cada vez que una herramienta agrupa una solución y una opinión en un solo paso indiferenciado, la opinión deja de parecer una elección. Empieza a parecer un valor por defecto; algo que nadie tiene que justificar, porque llegó antes de que se preguntara a nadie. Vale la pena preguntar, la próxima vez que un reset entre en un proyecto nuevo: qué líneas están arreglando algo real y cuáles son simplemente el gusto de alguien, vistiendo la ropa de una solución.

Most CSS Resets Solve the Wrong Problem

Franklin — Tue, 04 Aug 2026 11:14:46 +0000

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.