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ó.
