El artÃculo del jueves describió el orden en que el navegador resuelve los conflictos de CSS: primero origen e importancia, luego el orden de las capas, después la especificidad y, por último, el source order, con la herencia por debajo de todo. Describir un orden es una cosa. Verlo funcionar en un conflicto real es otra. Esto es eso.
También disponible en Inglés
La preparación (The Setup)
Un botón. Seis declaraciones. Todas compiten por la misma propiedad, abarcando cada etapa de la secuencia de resolución:
/* UA stylesheet — browser default */
button { color: buttontext; }
/* Author, @layer base (declared first) */
@layer base {
.btn { color: black; }
}
/* Author, @layer utilities (declared after base) */
@layer utilities {
.text-blue { color: blue; }
}
/* Author, unlayered */
#submit { color: red; }
/* Author, !important */
@layer base {
.btn { color: purple !important; }
}
/* User stylesheet — e.g. a browser accessibility override */
button { color: green !important; }
<button id="submit" class="btn text-blue">Submit</button>
¿Qué color gana?
Etapa uno: Origen e importancia
Esta etapa se comprueba antes de consultar cualquier otra regla de la lista y termina el conflicto de inmediato: gana el color verde (green).
No ocurre por ser el selector más especÃfico. No lo es; un selector simple como button es tan poco especÃfico como se pueda imaginar. Gana porque un !important con origen de usuario (user-origin) supera a un !important con origen de autor (author-origin). Es el único punto donde la lógica habitual el autor supera al usuario se invierte.
Cabe preguntarse por qué la plataforma está construida asÃ. La razón es breve y sólida: el usuario a veces necesita una forma de sobrescribir los estilos del autor que le perjudican. Un sitio que define un texto demasiado pequeño para leerse, o una combinación de colores que no cumple con sus necesidades de contraste. Si el !important del autor siempre superara al !important del usuario, esa sobrescritura serÃa imposible de aplicar, sin importar la configuración del navegador o de la tecnologÃa de asistencia. Los ajustes de accesibilidad deben mantener su autoridad. Por eso la cascada otorga la última palabra al !important de usuario, especÃficamente para garantizar que esa regla se cumpla.
No es un caso extremo oculto en la especificación. Es la razón de ser de esta etapa del algoritmo.
Etapa dos: Orden de capas (Layer Order)
Elimina las dos declaraciones !important la sobrescritura del usuario y la del autor y observa lo que queda: cuatro declaraciones de importancia normal, distribuidas en la hoja de estilo del agente de usuario (UA stylesheet), dos capas de autor (authored layers) y una regla sin capa (unlayered).
El orden de las capas resuelve esto antes de llegar a la especificidad. La regla sin capa #submit { color: red; } supera a cualquier regla con capa, sin condiciones. Los estilos sin capa siempre ganan a los estilos con capa, sin importar cuán pesado o ligero sea el selector dentro de ella. El color rojo (red) gana esta ronda.
Deja de lado la regla sin capa por un momento. La comparación se vuelve más interesante: .btn en base contra .text-blue en utilities. utilities se declaró después de base, por lo que .text-blue habrÃa ganado. No porque el color azul (blue) tenga un selector más especÃfico que el negro (black) no es asÃ, ambos son clases individuales, sino porque la capa en la que reside se declaró más tarde. Este es el mecanismo exacto descrito en el artÃculo sobre Cascade Layers, operando ahora frente a otras etapas reales en lugar de analizarse de forma aislada.
Etapa tres: Source Order, en aislamiento
Simplifica el ejemplo una vez más. Misma capa, misma especificidad, dos declaraciones que solo difieren en cuál aparece más abajo en el archivo:
@layer base {
.btn { color: black; }
.btn { color: navy; }
}
El color azul marino (navy) gana. No habÃa nada más disponible para decidir misma capa, misma especificidad, por lo que el algoritmo cae en la última etapa: la regla que aparece más tarde en el orden del código (source order). Esta es la etapa que el artÃculo 6 mencionó pero nunca demostró. Aquà está, aislada, haciendo exactamente lo que indica la especificación y nada más.
Lo que esto realmente demuestra
Seis declaraciones. Cinco etapas distintas de una sola secuencia. Cada una solo se consulta porque las anteriores no lograron producir una decisión. En el momento en que el origen y la importancia resolvieron el ejemplo externo, las capas, la especificidad y el source order no fueron consultados. Resultaron irrelevantes en el instante en que el color verde (green) ganó. Esa es la estructura real del algoritmo: no una secuencia de desempate, sino una serie de compuertas de eliminación. La mayorÃa de los conflictos nunca superan la primera compuerta aplicable.
Referencia
El navegador ya tiene una arquitectura. La mayorÃa de los proyectos la ignoran.
