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.
Top comments (0)