El problema que todas las metodologías intentaban resolver

Es fácil leer BEM o ITCSS hoy y pensar que sus autores se complicaban la vida. No lo hacían: resolvían con convenciones de nombres un problema que el lenguaje no tenía forma de resolver, porque las herramientas que hoy das por hechas —capas, ámbito, especificidad cero, variables que viven en la cascada— no existían, ni estaban propuestas, ni había consenso de que hicieran falta. Entender el problema original es lo único que permite juzgar qué parte de esa disciplina sigue teniendo sentido y qué parte es ritual heredado.

Cuatro propiedades y una consecuencia

El CSS clásico tenía cuatro características que, por separado, son razonables, y que juntas producían un sistema imposible de escalar.

Un único espacio de nombres global. Todo selector que escribes compite con todo selector que exista en la página, venga de donde venga. No hay módulos, no hay importación con renombrado, no hay privado. .title de tu componente y .title de la biblioteca de terceros que integraste el mes pasado son la misma cosa.

Alcance no acotado. Un selector descendente como .sidebar a alcanza a cualquier enlace que aparezca en cualquier profundidad dentro de un .sidebar, presente o futuro. En el momento de escribirlo eso parece una ventaja: escribes poco y cubres mucho. Seis meses después, cuando alguien mete un componente nuevo en la barra lateral, tu regla lo alcanza sin que nadie lo pretendiera y nadie sabe de dónde viene el subrayado.

Especificidad acumulativa e irreversible. Cuando dos reglas compiten, gana la más específica. Y como la única herramienta que tienes para ganar es añadir especificidad, la única jugada disponible en cada conflicto es escribir un selector más específico que el anterior. Eso no converge: escala. La partida termina siempre en el mismo sitio, y el sitio se llama !important.

Sin recolección de basura. Nada te dice qué reglas ya no se usan. Un selector sigue en el fichero para siempre porque nadie puede demostrar que borrarlo es seguro. La hoja crece de forma monótona, y a partir de cierto tamaño el coste de leerla supera el coste de añadirle algo, con lo que todo el mundo añade y nadie borra.

La consecuencia de las cuatro juntas tiene una firma reconocible. Un fichero de miles de líneas donde las últimas doscientas son parches. Selectores de siete niveles. Un !important cada treinta líneas. Reglas duplicadas con valores casi iguales. Y el síntoma definitivo: nadie del equipo se atreve a borrar nada, así que la hoja solo crece.

Por qué la especificidad escala

Merece la pena detenerse en el tercer punto porque es el motor de casi todo el daño y es el peor entendido.

Imagina dos desarrolladores trabajando en la misma hoja. El primero escribe .boton { background: azul }. El segundo necesita que el botón de la barra sea rojo y escribe .barra .boton { background: rojo }. Perfectamente razonable. El primero necesita ahora que el botón deshabilitado sea gris incluso en la barra, y escribe .barra .boton.deshabilitado. El segundo necesita una excepción en la barra de la página de checkout, y escribe #checkout .barra .boton. Y así.

Cada paso es local y sensato. Ninguno es un error. Pero el sistema completo tiene una propiedad terrible: la especificidad solo puede subir. No existe forma de decir “esta regla debe perder”, porque no hay especificidad negativa. La única acción disponible en un conflicto es incrementar, y como cada incremento hace más difícil el siguiente conflicto para todos los demás, el equilibrio del sistema es un solo punto: el máximo. Un #id .clase .clase que nadie puede vencer sin recurrir a !important, momento en el que empieza otra escalada idéntica un nivel más arriba.

Esto no es un fallo de disciplina. Es un fallo de diseño del lenguaje que solo se pudo arreglar cuando llegaron dos cosas: :where(), que permite escribir un selector con especificidad cero —o sea, una regla que pierde a propósito—, y @layer, que separa el orden de la especificidad y permite decir “esta capa entera pierde contra aquella, digan lo que digan los selectores”.

El orden y la fragilidad

Hay un quinto factor que se menciona menos y causa la mitad de los bugs de integración: cuando la especificidad empata, gana el que viene después en el orden del documento. El orden depende del orden de los @import, del orden en que el empaquetador concatena ficheros, y —en cuanto hay carga diferida— del orden en que llegan las respuestas de red.

Es decir: en una aplicación con división de código, el resultado visual podía depender de qué fragmento de CSS terminaba de descargarse antes. Eso convertía un bug de estilo en un bug de concurrencia, con toda la diversión que eso implica: no reproducible en local, aparece solo con red lenta, desaparece al abrir las herramientas de desarrollo.

Todas las metodologías clásicas dedican una parte importante de sus reglas a hacer que el orden no importe, precisamente porque no había forma de controlarlo. BEM lo consigue haciendo que dos reglas casi nunca compitan. ITCSS lo consigue imponiendo un orden global explícito y prohibiendo saltárselo. Son dos estrategias distintas para el mismo agujero.

Cronología de lo que faltaba

Situar las fechas cambia por completo la lectura de cada metodología, porque hace evidente que ninguna podía usar lo que no existía.

Fíjate en la última columna de 2009: todo lo demás. Nicole Sullivan escribió OOCSS con selectores y nada más. Harry Roberts escribió ITCSS sin capas en cascada. El autor de BEM no tenía @scope. Cuando leas sus reglas, la pregunta correcta no es “¿esto sigue siendo buena idea?” sino “¿qué mecanismo del lenguaje falta aquí, y ya existe?”. Esa pregunta reorganiza toda la disciplina clásica, y es la que recorre las cuatro lecciones siguientes.