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