Field notes: the resolution of the cascade, from beginning to end

La cascada CSS es el sistema que usa el navegador cuando varias declaraciones intentan establecer la misma propiedad. Su función es resolver el conflicto y producir un estilo final para cada elemento. Esto permite combinar reglas de distintos archivos, capas, selectores y orígenes sin resultados ambiguos.

Según el artículo, el navegador compara primero el origen y la importancia. Después revisa el orden de las capas, la especificidad y, finalmente, el orden del código fuente. Por ejemplo, una declaración importante puede superar a otra normal antes de que la especificidad importe. Una regla más específica no puede avanzar si ya perdió en una etapa anterior.

La cascada sigue siendo fundamental en CSS moderno. Entender su secuencia evita soluciones frágiles, como añadir selectores cada vez más largos. También ayuda a depurar conflictos reales: hay que identificar primero qué etapa decidió el resultado, en lugar de mirar únicamente qué regla parece más poderosa.

En el ejemplo del artículo, seis declaraciones compiten por una propiedad del mismo botón. El número importa porque permite observar cómo el navegador elimina candidatas progresivamente. No se trata solo de comparar dos reglas parecidas, sino de seguir un conflicto construido para mostrar toda la secuencia.

Las seis declaraciones pueden diferir en aspectos como origen, importancia, capa, especificidad y posición en el código. El navegador no las trata como una lista donde siempre gana la última. Primero descarta las que pierden en origen o importancia; después compara las capas que siguen. Solo entonces necesita calcular especificidad y revisar el orden de aparición.

Este ejemplo convierte una explicación abstracta en una prueba visible. Aunque el artículo introductorio disponible no enumera aquí el contenido exacto de cada declaración, sí establece claramente que son seis y que todas apuntan a la misma propiedad. Por eso, el resultado final depende de la cascada completa.

El navegador resuelve el conflicto en una secuencia fija. Primero compara el origen y la importancia de las declaraciones. Después considera el orden de las capas de cascada. Entre las candidatas que sobreviven, compara la especificidad. Si todavía hay empate, gana la declaración que aparece después en el código fuente.

Ese orden cambia cómo conviene leer un conflicto. Una regla con muchos selectores no vence automáticamente a una regla menos específica. Si la primera pierde por origen, importancia o capa, la especificidad deja de ser relevante. Del mismo modo, el orden del código fuente solo decide entre declaraciones que ya empataron en las etapas anteriores.

El artículo presenta exactamente esta secuencia: origen e importancia, capas, especificidad y source order. También sitúa la herencia por debajo de todo. Recordar el orden permite diagnosticar de arriba abajo y evita saltar directamente a aumentar la especificidad.

Cuando una declaración pierde en origen, importancia o capas, el navegador la descarta como candidata para ese conflicto. Ya no participa en las etapas posteriores. Por eso, una especificidad enorme no puede recuperar una regla que fue derrotada antes en la cascada.

Imagina una declaración con un selector muy preciso, pero marcada como normal, frente a una declaración importante que establece la misma propiedad. La declaración importante gana en la etapa correspondiente. El navegador no continúa comparando sus selectores para permitir que la regla normal se imponga. Lo mismo ocurre si una declaración queda por detrás debido al orden de capas.

Esta consecuencia es una de las lecciones centrales del artículo. La cascada no suma todas las ventajas de una regla en una sola puntuación. Las etapas funcionan en orden. Para depurar, primero hay que comprobar origen, importancia y capas; solo después tiene sentido investigar la especificidad.

El source order, u orden del código fuente, actúa como desempate final entre declaraciones que siguen empatadas. Si dos reglas tienen el mismo origen, importancia, capa y especificidad, el navegador elige la que aparece más tarde en la hoja de estilos. La posición final importa solo dentro de ese empate.

Por ejemplo, dos selectores de clase pueden establecer un color distinto para el botón. Si ambas reglas pertenecen a la misma capa y tienen la misma importancia, la segunda regla escrita gana. El navegador no necesita hacer el selector más largo ni añadir una clase artificial. Basta con colocar la declaración posterior, siempre que no cambien las demás condiciones.

El artículo sitúa explícitamente el source order al final de la secuencia. Esto ofrece una solución simple para conflictos equivalentes, pero no reemplaza la comprensión de capas o especificidad. Una regla posterior no puede derrotar por sí sola una declaración que ya ganó una etapa superior.

La herencia permite que ciertos valores pasen de un elemento padre a sus descendientes. Sin embargo, un valor heredado no compite en igualdad con una declaración aplicada directamente al elemento. Cuando el botón tiene una declaración válida para esa propiedad, normalmente usa ese valor propio y no el recibido del padre.

Por ejemplo, un contenedor puede declarar un color azul, y el botón puede declarar un color rojo. El botón mostrará rojo porque su valor está especificado directamente. Si se elimina la declaración del botón, el valor azul del padre puede heredarse, siempre que la propiedad sea heredable y no exista otro valor aplicable. Esta explicación sigue la jerarquía descrita en el artículo.

La herencia queda por debajo de todas las etapas de la cascada. Por eso, aumentar la especificidad de una regla heredada no suele resolver un conflicto contra una declaración directa. Primero se busca un valor aplicable al elemento; solo después entra en juego la herencia.

El navegador convierte muchas reglas CSS en un solo estilo aplicando filtros sucesivos. Primero decide qué declaraciones tienen prioridad por su origen y su importancia. Después compara las capas de cascada. Entre las declaraciones restantes, usa la especificidad del selector. Si persiste el empate, elige la que aparece más tarde en el código fuente.

El ejemplo del artículo muestra este mecanismo con seis declaraciones sobre una propiedad del botón. Una declaración puede quedar eliminada por su origen, importancia o capa antes de que importe su selector. Otra puede sobrevivir hasta especificidad y todavía perder frente a una regla equivalente escrita después. La herencia queda por debajo de estas decisiones y aporta un valor solo cuando corresponde.

Este modelo explica por qué CSS puede manejar reglas de usuario, autor, capas y selectores sin mezclarlos arbitrariamente. También orienta la depuración actual: revisar cada etapa en orden suele ser más eficaz que añadir !important o aumentar selectores. Comprender la cascada produce estilos más previsibles y mantenibles.