Leer la cascada real en el panel de estilos
Qué te está diciendo exactamente el orden de las reglas, qué significa cada tachado, cómo se ven las capas, y las funciones del panel que casi nadie usa y resuelven bugs en segundos.
El panel de estilos no muestra tu CSS: muestra el resultado de la cascada aplicada a un elemento concreto, que es una cosa distinta y mucho más informativa. Leerlo bien significa entender por qué las reglas están en ese orden, qué implica cada línea tachada y dónde está la información que el panel no te enseña hasta que se la pides. La mayoría de los bugs de estilo que a alguien le llevan veinte minutos se resuelven en treinta segundos si sabes qué estás mirando.
- Interpretar el orden en que el panel lista las reglas y qué significa.
- Distinguir los tres motivos por los que una declaración aparece tachada.
- Localizar las capas en cascada y la sección de propiedades heredadas.
- Usar los estados forzados y la edición en vivo como instrumento de diagnóstico.
El orden lo dice todo
El panel lista las reglas que coinciden con el elemento de la que gana a la que pierde, de arriba abajo. Ese orden es el resultado de la cascada completa, no del orden de tus ficheros, y por tanto ya incorpora el origen, la importancia, las capas, la especificidad y el orden del documento.
Eso convierte el panel en la herramienta más directa para responder la única pregunta que importa en un bug de cascada: quién gana y por qué. La regla que gana está arriba. Si la tuya no está arriba, todo lo que está por encima es la lista de sospechosos, ordenada.
Debajo de las reglas coincidentes hay dos bloques que se pasan por alto y que resuelven una clase entera de bugs.
Los estilos del elemento. El bloque de la parte superior con el atributo style en línea. Si hay algo ahí que no has escrito tú, lo ha puesto JavaScript, y en una aplicación con animaciones o con bibliotecas de posicionamiento eso pasa constantemente. Es el primer sitio donde mirar cuando un valor cambia solo.
La sección de propiedades heredadas. Al final del panel, agrupadas por el antepasado del que vienen. Es donde se ve que tu texto es gris porque un div cuatro niveles más arriba declaró un color, no porque ninguna regla del elemento lo diga. Cuando buscas la regla que produce un valor y no aparece en ningún sitio, casi siempre es porque la propiedad se hereda y estás mirando el elemento equivocado.
Los tres tachados
Una declaración tachada significa “esta declaración no está en efecto”, pero hay tres motivos distintos y confundirlos hace perder tiempo.
Tachada porque otra regla gana. El caso normal. La misma propiedad está declarada en una regla que aparece más arriba. Localizar al ganador es leer hacia arriba hasta encontrar la primera aparición de esa propiedad. Si la ganadora es tuya, es un conflicto de tu código; si es de una biblioteca, es un problema de orden o de capa.
Tachada porque el valor es inválido. El panel suele acompañarlo de un icono de advertencia. Ocurre con erratas —colour, 1 rem con espacio, #ff incompleto—, con unidades incorrectas y, muy frecuentemente, con un var() que no resuelve porque el token no está declarado en ningún ancestro. Es el caso descrito en el nivel de tokens, y aquí es donde se ve: la declaración aparece tachada y el valor real viene de otro sitio.
Tachada porque la propiedad no aplica a ese elemento. width en un elemento en línea, gap en un elemento que no es contenedor flex o grid, align-items en un bloque normal. La declaración es válida y no hace nada. Firefox es especialmente bueno aquí: marca la declaración como inactiva y te dice por qué, con una frase concreta del tipo “no tiene efecto porque el elemento no es un contenedor flexible”. Es una función que ahorra horas y que mucha gente que trabaja solo en Chrome no sabe que existe.
El campo de filtro sobre la lista de reglas oculta todo lo que no contenga el texto que escribes, manteniendo el orden de la cascada. Escribir margin en un elemento con veinte reglas aplicadas deja a la vista exactamente las declaraciones de margen que compiten, en orden de victoria. Para un bug de espaciado es la operación más rápida que existe.
Ver las capas
Con @layer en juego, la especificidad deja de explicar quién gana y hay que ver el orden de capas. Los navegadores lo exponen de dos formas.
En el panel de estilos, cada regla que vive en una capa aparece anotada con el nombre de su capa, normalmente encima del selector. Con eso ya se puede razonar: una regla de una capa posterior gana a una de una capa anterior aunque su selector sea más simple, y ver el nombre convierte un resultado desconcertante en uno esperado.
Además hay una vista dedicada que lista todas las capas del documento en su orden real, incluidas las anónimas y las anidadas. Es el sitio donde se comprueba lo que en la práctica es el bug de capas número uno: que el orden efectivo no es el que creías porque una capa se declaró implícitamente antes de tu declaración de orden. Recuerda que la primera vez que se menciona una capa se fija su posición: si un @import de terceros crea utilidades antes de que tu @layer reset, base, utilidades se ejecute, el orden real es otro.
Conviene tener presente una cosa que el panel no destaca lo suficiente: las reglas sin capa ganan a todas las capas. Si una declaración tuya de una capa pierde contra algo que parece más débil, comprueba si el ganador está simplemente fuera de todas las capas.
Los instrumentos del panel
Los estados forzados
El botón de estados forzados —etiquetado con los dos puntos y las siglas de hover en la mayoría de los inspectores— permite activar :hover, :active, :focus, :focus-visible, :visited y :target sobre un elemento y mantenerlos activos mientras inspeccionas.
Es imprescindible por un motivo mecánico: para ver el estilo de hover de un elemento tendrías que tener el puntero encima, y para inspeccionarlo tienes que mover el puntero al panel. Sin estados forzados, el estilo que quieres ver desaparece justo cuando vas a mirarlo.
Su uso más valioso no es ver el hover, sino comprobar el foco. Forzar :focus-visible y revisar que el indicador es visible, que tiene contraste suficiente contra todos los fondos posibles y que no lo recorta ningún overflow: hidden es una comprobación de accesibilidad que se hace en diez segundos y que casi nadie hace.
Junto a él está el botón de añadir clase, que permite escribir un nombre de clase en el elemento seleccionado sin tocar el DOM. Es la forma más rápida de comprobar si una clase de estado produce el efecto que esperabas antes de escribir el JavaScript que la aplicaría.
La edición en vivo como instrumento
El panel permite editar cualquier declaración, activar y desactivar declaraciones individuales con su casilla, y añadir reglas nuevas. Eso se usa habitualmente para probar diseños, y es más útil todavía como instrumento de diagnóstico si lo usas de forma sistemática en lugar de a tientas.
La técnica que más rinde es la bisección por desactivación. Ante un elemento que se comporta de forma inexplicable, desactiva la mitad de sus declaraciones. Si el problema desaparece, está en esa mitad; si no, en la otra. Cuatro o cinco pasos aíslan la declaración culpable entre treinta, y no requiere entender nada del problema. Es especialmente eficaz con bugs donde la causa es una propiedad que no sospechas: un overflow, un contain, un transform puesto por otra persona hace un año.
La versión ampliada de la misma técnica se hace en el árbol del DOM: borrar subárboles enteros hasta que el problema desaparece, para localizar qué elemento lo provoca. El DOM se recupera recargando, así que el coste de equivocarse es cero.
Y hay un detalle que conviene conocer: el panel de cambios acumula todas las ediciones que has hecho en la sesión como un diferencial. Cuando has llegado a una solución tras veinte pruebas, ese panel es la lista exacta de lo que hay que llevar al código, y evita el error clásico de trasladar la mitad.
Hay un cambio de actitud que separa a quien depura CSS con eficacia de quien lo hace a base de probar cosas, y no es conocimiento de herramientas: es qué haces cuando lo que ves no coincide con lo que esperabas. La reacción habitual es tratarlo como un obstáculo —“pues no sé por qué está tachado, voy a poner un !important”— y esa reacción es exactamente la que garantiza que el mismo bug vuelva en otro sitio dentro de tres semanas. La reacción productiva es tratarlo como el dato más valioso que vas a obtener hoy: el navegador ha aplicado las reglas de la cascada correctamente, tú predijiste otra cosa, y por tanto tu modelo de la cascada tiene un error concreto y localizado que acabas de encontrar gratis. Persíguelo hasta el final aunque el bug ya esté resuelto. Ese hábito tiene un rendimiento compuesto que es difícil de exagerar: cada discrepancia que investigas hasta entenderla elimina una categoría entera de bugs futuros, porque los errores de modelo mental no son aleatorios, se repiten en todo lo que escribes. Y tiene un efecto secundario práctico: la gente que hace esto acaba depurando por lectura —mira el panel, ve la anomalía, sabe qué la causa— mientras que la gente que no lo hace sigue depurando por prueba y error diez años después, con las mismas herramientas y el mismo tiempo por bug.