El CSS no necesita más poder — necesita mejores límites

También disponible en English.

El problema

Un equipo se enfrenta a un problema de estilos con el que el CSS no coopera. Algo debe cambiar basándose en un clic, una posición de desplazamiento o un estado de la aplicación. Entonces, buscan más poder.

Un selector más pesado. Un !important. A veces se ignora el CSS por completo: element.style.display = 'none', definido directamente desde un manejador de clics, porque se sentía más fiable que confiar en que la cascada hiciera lo pedido

Ninguno de los últimos tres problemas de esta serie se resolvió dando más capacidad al CSS. Los resets no se rompieron porque el CSS fuera demasiado débil para normalizar navegadores; se rompieron porque la opinión y la normalización compartieron un límite que nunca debió compartirse. La especificidad no se rompió porque los selectores fueran débiles; se rompió por no tener forma de declarar la intención independientemente del peso del selector. La entropía no fue causada por la falta de alguna característica; fue causada porque nada marcaba el límite entre lo que es seguro eliminar y lo que no.

Cada uno de esos fue un problema de límites. Ninguno fue un problema de poder.

Por qué existe el problema

El CSS se ganó su reputación de impredecible de forma honesta — de eso tratan los últimos tres artículos. Y la respuesta natural ante algo impredecible es rodearlo. JavaScript está ahí. Imperativo, potente, dispuesto a definir exactamente el valor que quieres en el elemento exacto que quieres, en el instante en que lo quieres.

Pero cada línea de lógica de presentación que se mueve a JavaScript es una línea que la cascada ya no puede ver ni razonar. Ahora es un valor compitiendo con reglas de CSS reales, de formas que la especificidad nunca fue construida para arbitrar y que las capas, una vez introducidas, tampoco podrán ver. La impredecibilidad no se arregla. Se traslada a un lugar aún menos estructurado: se dispersa entre manejadores de clics y ciclos de vida de componentes en lugar de estar contenida en una sola hoja de estilos donde, al menos, el problema era visible.

El primer principio

Un límite no es una limitación. Es una garantía.

El CSS ya posee cuatro cosas por derecho propio, con autoridad real otorgada por el navegador: presentación, transición, diseño (layout) y renderizado. No es una lista pequeña; el navegador entrega al CSS un control genuino sobre cómo se ve y se mueve casi todo en una página. El hecho menos valorado es que esto ya es suficiente. El instinto de buscar más allá del CSS no suele ser porque este carezca de capacidad en su función real. Es porque los bordes de esa función nunca se dibujaron explícitamente.

El CSS no debería poseer el estado de la aplicación. No debería codificar lógica de negocio. En el momento en que cualquiera de los dos se cuela —un nombre de clase que secretamente representa un valor de datos, un selector elegido basado en lo que devolvió el backend en lugar de lo que el elemento es— la garantía se rompe. Y no solo se rompe para quien escribió ese cruce. Se rompe para todos los que toquen ese código después, porque ahora ya no se puede confiar en que la presentación viva en un solo lugar.

Demostración del principio

Un interruptor (toggle), hecho de dos maneras.

Definido directamente desde un manejador de clics:

button.addEventListener('click', () => {
  panel.style.display = panel.style.display === 'none' ? 'block' : 'none';
});

O la misma interacción, con el límite intacto — JavaScript cambia el estado, el CSS posee la presentación resultante:

button.addEventListener('click', () => {
  panel.classList.toggle('is-open');
});

.panel {
  display: none;
}

.panel.is-open {
  display: block;
}

Mismo resultado para el usuario. Pero en la segunda versión, la presentación sigue siendo plenamente legible solo desde la hoja de estilos. Nadie tiene que ir a cazar a través del JavaScript para entender cómo se comporta .panel.

quell como estudio de caso

quell dibuja este límite explícitamente y lo trata como innegociable: el CSS posee la presentación, el JavaScript posee el comportamiento, el HTML posee la estructura. Nada en el sistema tiene permitido cruzar esa línea silenciosamente; una regla impuesta por convención tan firmemente como por arquitectur.

La lección general

Esto cierra las primeras cuatro piezas de esta serie, y vale la pena nombrar la forma que subyace a todas ellas.

Resets: algo que reclamaba una neutralidad que no tenía. Especificidad: algo calculando que debería haber estado declarando. Entropía: algo creciendo que debería haber sido gobernable. Y ahora esto: algo buscando poder cuando lo que realmente necesitaba era una línea que nadie había dibujado todavía
.
Cuatro síntomas diferentes. Una solución subyacente, nombrada claramente por primera vez aquí: límites, no poder. El resto de esta serie existe para mostrar exactamente cómo el navegador te permite construir límites de verdad — empezando por el mecanismo que le da a la cascada un eje de orden explícito propio.
.