También disponible en Inglés.
El problema
La última entrega terminó con una promesa: existe un mecanismo real para definir límites, nativo del navegador, sin necesidad de procesos de compilación.
La mayoría de las explicaciones sobre este mecanismo lo describen como una herramienta de especificidad; una forma de escribir selectores más débiles y aun así ganar el conflicto. Es cierto. También es la lectura superficial.
Esta es la lectura profunda. Antes de las Cascade Layers, los conflictos de estilos en cualquier equipo de tamaño considerable se resolvían de la misma forma: la gente hablaba entre sí. Alguien preguntaba si era seguro sobrescribir los estilos de un botón, y la respuesta venía de quien recordara la última vez que algo se rompió. Un ingeniero senior resolvía una discusión sobre qué selector debía ganar, de manera informal, en un hilo de conversación que nadie más volvería a encontrar. Eso es negociación. Y la negociación es lo que realmente se rompía al escalar, mucho antes que cualquier selector individual.
Por qué existe el problema
La precedencia basada en la negociación parece razonable cuando unas pocas personas retienen todo el contexto en sus cabezas. "No usamos IDs". "No toques ese archivo sin preguntar primero". "Consulta con Sarah antes de sobrescribir nada en los componentes". Reglas como estas funcionan mientras las personas que las crearon sigan en la sala, sigan recordando y sigan disponibles para ser consultadas.
No sobreviven al crecimiento, a la rotación de personal o al paso del tiempo. Es el mismo mecanismo de entropía mencionado anteriormente en esta serie, resurgiendo aquí de forma social en lugar de forma de código. La especificidad, bajo esta luz, no era realmente el campo de batalla. Era el síntoma: el lugar donde se luchaban los desacuerdos no resueltos sobre la propiedad y la intención, selector por selector, porque no había otro lugar para que ese desacuerdo existiera.
El primer principio
Este es el cambio que vale la pena nombrar con precisión: las Cascade Layers no solo añaden una nueva regla de precedencia. Reemplazan un mecanismo social por uno declarado.
@layer theme, tokens, base, layout, components, interactive, utilities, overrides;
Una línea. Declarada una vez. Aplicada por el navegador después, sin excepciones y sin dejar nada que nadie deba recordar, preguntar o negociar de nuevo. El orden deja de ser conocimiento tribal transmitido en conversaciones de integración o en el historial de Slack. Se convierte en código fuente: visible, versionado y real para cada colaborador, haya estado o no en la sala donde se tomó el acuerdo original.
Demostración del principio
@layer components, utilities;
@layer components {
.card .title { font-size: 1.25rem; }
}
@layer utilities {
.text-lg { font-size: 2rem; }
}
.text-lg gana. No por escribir un selector más pesado o escalar a !important; nadie tuvo que pedir permiso primero. El orden ya estaba establecido antes de escribir cualquiera de las dos reglas, porque se declaró una vez al principio del archivo.
quell-base.css como caso de estudio
quell-base.css es la base real sobre la que se construye esta tesis. Declara cinco capas, en este orden exacto:
@layer ghost_tokens, reset, baseline, forms, utilities;
Cada capa no solo posee una categoría de estilo; resuelve de antemano una discusión que, de otro modo, tendría que negociarse cada vez que surgiera.
- ghost_tokens: valores de respaldo totalmente resueltos, analizados por el navegador antes de la primera pintura. Resuelve, de antemano, si una llamada
var()queda apuntando a la nada mientras se carga una hoja de temas. No hay condiciones de carrera que negociar, porque el respaldo nunca estuvo en duda. - reset: inconsistencia del navegador borrada, con cero opinión visual. Esta es la distinción exacta del primer artículo, aplicada como política en lugar de ser discutida más tarde: la normalización vive aquí, y solo aquí, para que nadie tenga que preguntar si "reset" significa secretamente "el gusto de alguien".
- baseline: diseño visual mínimo, consumiendo tokens en lugar de inventar valores propios. Establece, permanentemente, que esta capa renderiza decisiones tomadas en otro lugar; no toma decisiones nuevas.
- forms: elementos de formulario aislados en su propia superficie, normalizados aparte de todo lo demás. Nadie tiene que negociar si el reset de un
<button>pertenece a la misma conversación que el de un<input>; el límite ya está trazado. - utilities: intencionalmente vacía en el archivo central, reservada y con la prioridad más alta por declaración. Cualquier cosa que un equipo descendente añada aquí ganará a cada capa superior, automáticamente, porque eso se decidió de antemano y no se dejó para que alguien ganara después con un selector más pesado.
Nada de esto requirió una reunión. Nada de esto requiere que el autor original siga en el equipo para que continúe funcionando. El archivo lo establece casi como una garantía propia: tres superficies de sobrescritura explícitas, clasificadas en poder ascendente. Redecleara un token en :root, fuera de cualquier capa, y gana. Abre de nuevo @layer baseline {} en una hoja descendente, y la adición aterriza exactamente donde se pretendía. Escribe una regla sin capa y vencerá a cada capa mencionada anteriormente, sin condiciones. Las propias palabras del archivo para definir lo que esto ofrece: "No se requiere !important.".
El acuerdo es ahora la arquitectura, no un recuerdo que un puñado de personas debe mantener vivo.
La lección general
Cualquier equipo, de cualquier tamaño, necesita eventualmente una forma de resolver reclamos en conflicto sobre la autoridad. La mayoría de los sistemas, en código o fuera de él, optan por la negociación: quien sea más senior en la sala, o simplemente más insistente en el momento, gana. Ese enfoque parece natural porque es como comienzan la mayoría de los sistemas humanos. Pero no escala, y no sobrevive a la partida de las personas que lo construyeron.
El orden declarado y aplicado sí sobrevive. Eso es lo que las Cascade Layers realmente reemplazaron: no un selector más débil, sino una negociación que nadie quería seguir teniendo. La arquitectura es lo que permite que un acuerdo sobreviva a la reunión donde se creó.
