Por qué está tachado: las cinco causas y cómo distinguirlas
Una declaración tachada puede significar cinco cosas muy distintas con cinco arreglos incompatibles, y el panel da pistas suficientes para saber cuál es en cada caso.
El tachado del panel de estilos es la señal de diagnóstico más usada de todo el CSS y también la peor interpretada. Casi todo el mundo la lee como “esta regla ha perdido la cascada” y sube la especificidad, cuando en realidad hay cinco motivos distintos por los que una declaración aparece tachada y solo uno de ellos se arregla tocando el selector. Los otros cuatro empeoran con esa reacción.
- Distinguir las cinco causas de tachado a partir de las señales del panel.
- Aplicar el arreglo correcto a cada una sin recurrir a la especificidad como reflejo.
- Reconocer el caso más silencioso, el de la propiedad que no aplica a ese tipo de caja.
- Explicar por qué un shorthand escrito después puede tachar una declaración más específica.
Las cinco causas
Causa 1: perdió la cascada
Es la que todo el mundo asume y es la más común, aunque no por tanto margen como se cree. Otra declaración con mayor prioridad definió la misma propiedad, y esa declaración está más arriba en el panel.
La señal inequívoca: la misma propiedad aparece sin tachar en algún bloque superior. Si haces scroll hacia arriba y la encuentras, es este caso y el diagnóstico está cerrado.
El arreglo por defecto —subir la especificidad— es casi siempre el peor de los posibles, porque inicia una carrera armamentística que en seis meses deja el proyecto lleno de selectores de cuatro clases encadenadas. Las alternativas por orden de preferencia: mover la regla más abajo en el mismo fichero si ambas tienen la misma especificidad, usar capas de cascada para declarar explícitamente qué grupo gana, o revisar si la regla ganadora debería existir siquiera.
Causa 2: la propiedad no existe
Escribiste colour, font-weigth, o una propiedad que existe en otro motor pero no en este. El navegador la descarta al parsear y el panel la tacha.
La señal: junto a la declaración aparece un icono de aviso, y el nombre de la propiedad no tiene el color habitual del resaltado de sintaxis. Al pasar el cursor sobre el aviso, el mensaje dice que la propiedad no es reconocida.
Es el caso más fácil de arreglar y el más fácil de pasar por alto cuando el error tipográfico es sutil. El panel de problemas del cajón inferior también recoge estos casos, lo que da una lista de todos los errores de sintaxis de la página de golpe.
Causa 3: el valor es inválido para esa propiedad
La propiedad existe pero el valor no le sirve: width: 100, sin unidad; color: #GGG; display: flexbox. El parser descarta la declaración entera.
La señal es la misma que en el caso anterior —icono de aviso— pero el mensaje distingue: dice que el valor no es válido, no que la propiedad no lo sea. Esa diferencia en el texto del aviso es la que separa las causas 2 y 3, y merece la pena leerla en vez de asumir.
Hay una variante que engaña más: los valores que dependen del contexto. width: 100% es válido siempre, pero solo hace algo si el contenedor tiene un ancho definido. Eso no aparece tachado, porque la declaración es perfectamente válida; simplemente resuelve a algo que no esperabas. Esa es la trampa que separa el tachado de la ineficacia.
Causa 4: la propiedad no aplica a ese tipo de caja
La causa más silenciosa y la que más tiempo consume. La declaración es válida, gana la cascada, no está tachada por conflicto, y no hace nada, o aparece tachada con un aviso que la mayoría de la gente no sabe interpretar.
Los casos canónicos.
width y height sobre un elemento inline no generado por reemplazo: no tienen efecto. Un span sin display cambiado ignora el ancho.
vertical-align sobre un elemento que no es inline ni celda de tabla: no hace nada.
Las propiedades de alineación de flex sobre un contenedor que no es flex, o las de grid sobre uno que no es grid.
top, left, right y bottom sobre un elemento con position: static: ignoradas.
z-index sobre un elemento que no crea contexto de apilamiento y no está posicionado: ignorado.
Las DevTools señalan varios de estos casos con un aviso específico que dice que la propiedad no tiene efecto por el valor de otra propiedad, y a veces indican cuál. Es la mejor pista que da el panel y la menos leída.
Este caso es el que produce la conversación circular de “pero si lo tengo puesto”. Lo tienes puesto y el motor lo está ignorando porque la caja no es del tipo que admite esa propiedad. El arreglo nunca es más especificidad: es cambiar el tipo de caja, o usar la propiedad que sí corresponde a ese contexto.
Causa 5: un shorthand posterior la sobrescribió
Es la más contraintuitiva y produce bugs que parecen imposibles. Los shorthands escriben todas sus sub-propiedades, incluidas las que no mencionas, con sus valores iniciales.
.tarjeta {
background-image: url("fondo.jpg");
background: #222; /* borra la imagen */
}La segunda declaración es un shorthand de background que fija background-image a none porque no la mencionas. En el panel verás background-image tachada en la primera declaración, con la ganadora siendo un shorthand que aparentemente no habla de imágenes.
El panel ayuda: los shorthands se pueden expandir con el triángulo que llevan al lado, y al expandirlos se ven todas las sub-propiedades con sus valores efectivos, incluidos los implícitos. Ese despliegue es la prueba directa de la causa.
Las familias donde más ocurre son background, font, border, grid, flex, transition y animation. La de font es especialmente destructiva porque restablece line-height a normal si no lo especificas dentro.
La tabla de diagnóstico
| Señal en el panel | Causa | Arreglo correcto |
|---|---|---|
| La propiedad aparece sin tachar más arriba | Perdió la cascada | Orden, capas o revisar la regla ganadora |
| Icono de aviso, mensaje sobre la propiedad | Propiedad inexistente | Corregir el nombre |
| Icono de aviso, mensaje sobre el valor | Valor inválido | Corregir el valor o la unidad |
| Aviso de que no tiene efecto por otra propiedad | No aplica a esa caja | Cambiar el tipo de caja o la propiedad |
| Un shorthand la sobrescribe desde abajo | Reset implícito | Reordenar o usar la longhand después |
| No aparece en absoluto | No casa | Ver la lección anterior: cinco causas de ausencia |
Hay dos malentendidos simétricos alrededor del tachado que conviene desmontar juntos, porque juntos explican por qué mucha gente lee mal este panel. El primero: la mayoría de los tachados de una página sana son completamente normales y no indican ningún problema. Cualquier proyecto con un framework de estilos tiene decenas de declaraciones tachadas en cada elemento, porque así es como funciona la cascada: reglas genéricas que declaran un valor por defecto y reglas específicas que lo sustituyen. Ver muchos tachados no significa que haya nada roto; significa que hay capas de estilos, que es lo normal. Ir a “limpiarlos” es trabajo perdido y a menudo dañino. El segundo malentendido es más caro: la ausencia de tachado no significa que tu regla esté funcionando. Una declaración perfectamente visible, sin tachar, en el bloque de arriba del todo, puede estar sin ningún efecto por la causa 4, y en muchos casos las DevTools no ponen ningún aviso porque no todas las combinaciones están cubiertas. El único test definitivo de que una declaración hace algo no está en este panel: está en el de computados. Si la propiedad computada tiene el valor que pusiste, la declaración funcionó. Si tiene otro, algo la sustituyó, y si tiene el valor inicial de la propiedad, probablemente nunca aplicó. Ese es el motivo por el que la secuencia correcta de diagnóstico de CSS es computados primero, panel de estilos después: computados te dice qué pasó, y el panel de estilos te dice por qué. Hacerlo al revés es empezar por la explicación de un hecho que todavía no has verificado.