Leer el panel de estilos como lo que es: la cascada resuelta
La anatomía completa del panel: qué orden tienen las reglas, de dónde viene cada bloque, qué significan los distintos orígenes y por qué el orden que ves no es el del fichero.
El panel de estilos no es una lista de las reglas de tu hoja de estilos: es el resultado de ejecutar el algoritmo de la cascada para el elemento seleccionado, presentado en el orden en que el motor lo resolvió. Leerlo como si fuera un fichero es lo que hace que la gente busque su regla donde no está y añada declaraciones que no hacen falta. Leerlo como lo que es convierte el panel en la respuesta directa a la pregunta más frecuente de todo el CSS: por qué gana lo que gana.
- Interpretar el orden de los bloques del panel como el orden de la cascada resuelta.
- Identificar el origen de cada bloque: elemento, autor, agente de usuario o herencia.
- Localizar el fichero y la línea reales de cualquier regla mostrada.
- Explicar por qué una regla que existe en tu CSS no aparece en el panel.
El orden del panel es el orden de la victoria
La regla estructural que hay que interiorizar antes que ninguna otra: el panel presenta las reglas que casan con el elemento ordenadas de mayor a menor prioridad en la cascada. La de arriba es la que gana, y cada declaración de las de abajo aparece tachada si alguna de arriba ya definió esa misma propiedad.
Eso significa que el orden no se corresponde con el orden de tu fichero, ni con el orden de carga de las hojas, ni con nada que puedas predecir mirando el código. Es la salida de un algoritmo que combina origen, capa, especificidad y orden de aparición, y ese algoritmo tiene una jerarquía que el panel refleja fielmente.
De arriba abajo, los bloques aparecen en este orden.
element.style, siempre el primero. Corresponde al atributo style del elemento, sea porque estaba en el HTML, porque un script lo puso, o porque tú editaste algo en el panel sin crear una regla. Gana a todo lo que no sea !important.
Las reglas de autor que casan con el elemento, ordenadas por prioridad de cascada. Aquí es donde vive el noventa por ciento de tu CSS.
Las reglas heredadas, agrupadas bajo encabezados que dicen de qué elemento se heredan. Cada grupo corresponde a un ancestro, y aparecen en orden ascendente por el árbol.
Las reglas del agente de usuario, que son la hoja de estilos por defecto del navegador. Están ocultas por defecto y hay un ajuste para mostrarlas. Merece la pena activarlo: explican por qué un button tiene ese borde, por qué un ul tiene ese sangrado y por qué un input no hereda tu fuente.
Las declaraciones marcadas con !important alteran el orden completo de una forma que el panel refleja pero que es fácil pasar por alto: una regla de autor con !important sube por encima de element.style sin !important. Si ves una regla aparentemente débil ganando desde abajo del panel, busca el !important.
De dónde viene cada bloque
A la derecha del selector de cada regla aparece su procedencia, y ese texto es un enlace. Los valores posibles dicen bastante.
Un nombre de fichero con número de línea significa una hoja de estilos externa. El enlace abre el fichero en Sources en esa línea exacta, y si hay un source map de CSS abre el fuente original —el .scss, el .less o el fichero antes de procesar— en vez del compilado.
El texto que indica el documento significa que la regla está en una etiqueta style dentro del HTML.
La referencia a la hoja del agente de usuario significa que es del navegador y que no la has escrito tú.
Una indicación de hoja inyectada aparece cuando la regla viene de una extensión, y esa es una información valiosísima: si un estilo inexplicable viene de una extensión, has terminado la investigación. Este es uno de los argumentos fuertes a favor de depurar con un perfil limpio.
Y las hojas de estilo construibles —creadas desde JavaScript con CSSStyleSheet y adoptadas por un documento o una raíz de sombra— aparecen identificadas como tales. Es lo habitual en componentes web modernos y en varias librerías de estilos en JavaScript.
Las tres secciones que la gente no mira
Debajo de las reglas hay tres cosas que resuelven preguntas concretas y muy frecuentes.
El modelo de caja interactivo. El diagrama de margen, borde, relleno y contenido con los valores reales. No es solo informativo: cada número es editable con doble clic, y pasar el cursor sobre cada zona la resalta en la página con el color correspondiente. Cuando algo tiene un espacio que no sabes de dónde sale, este diagrama lo responde en dos segundos y evita la búsqueda a ciegas por el CSS.
Las propiedades definidas por el elemento como contenedor. En elementos con container-type, el panel indica el contenedor de consulta y su tamaño actual, que es exactamente el dato que necesitas cuando una container query no dispara.
La lista de clases. El control que despliega las clases del elemento permite activarlas y desactivarlas con casillas, y añadir clases nuevas escribiendo. Es la forma más rápida que existe de probar un estado que en tu aplicación se representa con una clase: en vez de buscar cómo provocar el estado, marcas la clase y ves el resultado.
Es la situación que más desespera: sabes que has escrito la regla, la ves en tu editor, y en el panel no está por ningún lado. No tachada, sino ausente. Que una regla no aparezca significa una sola cosa —no casa con este elemento— y las causas son cinco, en orden de frecuencia real. La primera es que el selector no casa por un motivo trivial: una clase mal escrita, un guion de más, un espacio descendente donde querías un hijo directo. Se descarta en cinco segundos pegando el selector en la búsqueda del panel: si devuelve cero coincidencias, ya lo tienes. La segunda es que estás mirando otro elemento: en árboles con wrappers, seleccionar el nodo equivocado es constante, y la regla está aplicándose perfectamente al padre o al hijo. La tercera es que la hoja no se ha cargado: un 404, un fallo de MIME type, un import que no resolvió. El panel de red lo responde y hay que mirarlo antes de dudar del selector. La cuarta es que la regla está dentro de una at-rule que no se cumple: una media query que no aplica al ancho actual, un @supports con una condición falsa, un @container cuyo contenedor no tiene el tamaño necesario. El panel muestra las at-rules que sí se cumplen como encabezado sobre la regla; las que no se cumplen simplemente no salen, y esa ausencia parece la ausencia de la regla entera. La quinta, la más traicionera de todas, es la frontera del shadow DOM: si el elemento vive dentro de un componente con raíz de sombra, tus estilos globales sencillamente no entran, y no hay error, ni aviso, ni nada tachado. Solo silencio. La secuencia de comprobación que las cubre las cinco en menos de un minuto: pega el selector en la búsqueda del panel, confirma qué nodo tienes seleccionado, comprueba que la hoja cargó en Network, busca la at-rule que la envuelve, y mira si hay un #shadow-root entre tu elemento y el documento.
El filtro del panel
Arriba del panel hay un campo de filtro que casi nadie usa y que en elementos con cuarenta reglas es imprescindible. Filtra por nombre de propiedad y por valor a la vez, mostrando solo los bloques que contienen algo que casa, y mantiene el orden de la cascada.
Escribir color deja a la vista todas las declaraciones de color en todas las reglas que casan, en orden de prioridad, y con las perdedoras tachadas. Eso es, literalmente, la resolución de la cascada para esa propiedad presentada en cuatro líneas.
Es la herramienta correcta para la pregunta “de dónde sale este color”, más rápida y más informativa que ir al panel de computados, porque además de decirte el valor final te enseña a los perdedores y por qué perdieron.
Selecciona un párrafo cualquiera de una página real, activa la visualización de los estilos del agente de usuario, y cuenta cuántas reglas casan con él. En una aplicación con un framework de estilos suelen ser entre quince y cuarenta. Luego filtra por font y observa la cadena completa de quién intentó definir la tipografía y quién ganó. Es el mejor ejercicio de cascada que existe y no requiere leer ninguna especificación.