También disponible en Inglés
El problema
Pregunta a la mayoría de los desarrolladores cómo funciona la especificidad; sabrán explicarlo. Pregunta sobre la herencia; también sabrán explicarla. El orden de declaración, el origen, !important — casi todo esto se aprende por separado, por lo general al depurar un error, y se olvida en cuanto se apaga el incendio inmediato.
Casi nadie los aprende como un solo sistema.
El cambio de perspectiva que importa es este: el navegador no tiene seis datos de CSS inconexos dispersos en su motor de renderizado. Tiene un algoritmo completo y especificado para la resolución de la cascada; una respuesta real y ordenada a la pregunta "qué regla se aplica aquí", resuelta etapa por etapa. La mayoría de los proyectos nunca han leído ese algoritmo de principio a fin. Solo se han encontrado con él ante un diseño roto.
Por qué existe el problema
Estos mecanismos se enseñan por partes, porque así es como se necesitan. Un tutorial explica la especificidad porque la especificidad acaba de dar un problema a alguien. Una respuesta en Stack Overflow explica la herencia porque el tamaño de la fuente de alguien no se comportaba como debía. Cada explicación es precisa, acotada y está desconectada de las otras cinco etapas del mismo algoritmo que operan justo al lado.
Es una forma rápida de corregir un error. Es una mala forma de aprender un sistema. Un equipo puede entender la especificidad a fondo y, aun así, no saber que el origen, la importancia y el orden de las capas se resuelven antes de consultar la especificidad. Esto significa pasar horas luchando una batalla de especificidad que ya se había perdido, o ganado, en una etapa anterior que nadie pensó en verificar. Cuando esto ocurre con frecuencia, los equipos dejan de confiar en la cascada. En su lugar, construyen una arquitectura paralela encima de ella —convenciones de nomenclatura, herramientas de scoping, capas adicionales de abstracción— para resolver problemas que el propio algoritmo del navegador ya resuelve. Solo que no lo hace de manera visible, porque nadie leyó la secuencia completa.
El primer principio
Este es el orden real, presentado como una secuencia en lugar de un glosario de términos independientes.
El origen y la importancia se comprueban primero: estilos del navegador, estilos del autor, estilos del usuario y si !important está aplicado a alguno de ellos. Después, el orden de las capas (@layer) para cualquier declaración dentro de ellas; aunque cabe destacar que !important invierte este orden, haciendo que gane la primera capa declarada en lugar de la última. Luego se evalúa la especificidad, pero solo entre las reglas que sobrevivieron sin resolverse a las dos primeras etapas. Finalmente, el orden de declaración funciona como desempate cuando nada más lo ha solucionado. La herencia se ejecuta por debajo de toda la secuencia, proporcionando en silencio una respuesta para cualquier propiedad que los pasos anteriores no hayan abordado.
El cambio de perspectiva: nunca fueron cinco datos para memorizar por separado. Es un solo algoritmo ordenado, y cada una de esas palabras familiares (origen, capas, especificidad, orden de declaración, herencia) nombra una fase dentro de él. Aprendidos de forma aislada, son datos de trivia. Aprendidos como una secuencia, constituyen un contrato de ingeniería sobre el cual un equipo puede diseñar a propósito.
Demostración del principio
Una regla dentro de una capa con alta especificidad aún puede perder frente a una regla sin capa con mucha menos especificidad. No es un error; es la secuencia funcionando según lo especificado. El orden de las capas se resuelve antes de llegar a la especificidad. Para estilos normales, las reglas sin capa tienen prioridad sobre todas las capas explícitas, ganando independientemente de la especificidad. Para estilos con !important, esa prioridad se invierte, otorgando la ventaja a las reglas con capa. Conocer dónde se sitúan las capas en la secuencia en relación con el origen y la importancia marca la diferencia entre una sobrescritura inesperada y un sistema de diseño predecible.
quell como caso de estudio
La arquitectura de quell se mantiene de forma fiable en producción por una razón sencilla: fue diseñada con este orden de resolución completo en mente desde el principio, no armada mediante prueba y error contra reglas aisladas aprendidas de una en una.
La lección general
La mayoría de los problemas de ingeniería que parecen deberse a la falta de características son, en realidad, falta de comprensión de un sistema que ya se había proporcionado. El navegador no falló al darle una arquitectura a CSS. Proporcionó una completa, especificada, estable y estandarizada, y la mayoría de los proyectos construyen en silencio una segunda arquitectura informal encima de ella, porque la primera nunca se leyó en su totalidad.
Ese patrón no es exclusivo de CSS. Aparece en cualquier lugar donde un sistema se aprende en piezas desconectadas en lugar de como la secuencia única que realmente es: reinventar lo que ya existe, a un costo real, porque nadie se sentó a leer el conjunto de principio a fin.
Top comments (0)