DEV Community: Franklin

La mejor arquitectura CSS comienza al decidir qué no debe hacer CSS jamás

Franklin — Tue, 25 Aug 2026 10:36:43 +0000

También disponible en Inglés

El problema

Un sistema de tokens de diseño comienza limpio. Colores, espaciado, escala tipográfica; todos valores, todos legítimos. Luego, alguien necesita una forma rápida de rastrear si un modal está abierto, y una propiedad personalizada está justo ahí, sintácticamente idéntica a cada token a su alrededor. Se usa. Nadie se detiene a preguntar si debería haberse usado.

Una hoja de estilo comienza siendo solo para presentación. Luego aparece un selector que solo se aplica si el usuario ha iniciado sesión; una decisión que CSS no tiene por qué tomar, codificada en CSS de todos modos, porque en ese momento era el camino de menor resistencia.

Ninguna de las dos opciones parece incorrecta cuando se toma. El patrón en ambas es el mismo: nada en el sistema tenía argumentos para decir no.

Por qué existe el problema

Las conversaciones sobre arquitectura casi siempre comienzan con la misma pregunta: qué debe hacer este sistema. Es una pregunta natural y generativa, pero no tiene un punto de parada natural. Cada capacidad que alguien pueda imaginar es candidata para ser incluida, y rara vez hay un momento obvio para decir no, categóricamente, independientemente de lo conveniente que sea esto en este momento.

El resultado son sistemas que acumulan permisos por defecto. La restricción solo aparece de manera reactiva, después de que algo ya ha salido mal y alguien tiene que escribir la autopsia explicando cómo un booleano terminó viviendo dentro de un token de diseño.

El primer principio

Un sistema sin exclusiones declaradas eventualmente será requerido para hacerlo todo, porque nada dentro de él tiene argumentos para negarse.

Vale la pena decirlo claramente, porque invierte la forma en que la mayoría de la gente piensa sobre el diseño: las exclusiones no son la ausencia de arquitectura. Son su parte más resistente. Este es el mismo principio mencionado anteriormente en esta serie: un límite es una garantía, no una limitación, llevado un nivel más profundo. No solo dónde termina CSS y comienza JavaScript, sino lo que CSS se niega a convertirse mientras permanece por completo dentro de su propio dominio.

Demostración del principio

Sintaxis idéntica. Validez idéntica, en lo que respecta al navegador. Uno es un valor. El otro es estado de la aplicación, vestido de token, porque nada en la plataforma los distingue y nada en el diseño del sistema decidió hacerlo. El navegador nunca rechazará esto. El rechazo tiene que provenir de una decisión tomada de antemano; no de una limitación que la plataforma entregue gratis a nadie.

quell como caso de estudio

La capa de tokens de quell contiene valores, y solo valores. No porque la plataforma lo imponga, sino porque el sistema decidió, de antemano, no permitir que nada que se asemeje a estado o lógica viva allí.

La lección más amplia

Los sistemas más fuertes, tanto en el desarrollo de software como fuera de él, suelen definirse tanto por lo que han declarado que no harán como por lo que pueden hacer. Qué no debería hacer esto nunca es una pregunta más difícil que qué debería hacer esto, precisamente porque exige una decisión tomada de antemano, una que la conveniencia seguirá tentando silenciosamente a romper más tarde.

Esa es la diferencia entre un sistema que simplemente funciona hoy y uno construido para seguir teniendo sentido después de que la persona que lo escribió ya no sea quien responda las preguntas al respecto.

The Best CSS Architecture Starts by Deciding What CSS Should Never Do

Franklin — Tue, 25 Aug 2026 10:34:55 +0000

Also available in Español

The Problem

A design token system starts clean. Colors, spacing, type scale all values, all legitimate. Then someone needs a quick way to track whether a modal is open, and a custom property is right there, syntactically identical to every token around it. It gets used. Nobody stops to ask whether it should have been.

A stylesheet starts as presentation-only. Then a selector shows up that only applies if the user is logged in a decision CSS has no business making, encoded into CSS anyway, because in the moment it was the path of least resistance.

Neither choice looks wrong when it's made. The pattern across both is the same: nothing in the system had grounds to say no.

Why the Problem Exists

Architecture conversations almost always start with the same question: what should this system do. It's a natural question, and a generative one but it has no natural stopping point. Every capability someone can imagine is a candidate for inclusion, and there's rarely an obvious moment to say "no, categorically, regardless of how convenient this would be right now."

The result is systems that accumulate permission by default. Restriction only shows up reactively, after something has already gone wrong and someone has to write the postmortem explaining how a boolean ended up living inside a design token.

The First Principle

A system with no declared exclusions will eventually be asked to do everything, because nothing inside it has grounds to refuse.

This is worth stating plainly, because it inverts how most people think about design: exclusions aren't the absence of architecture. They're the most load-bearing part of it. This is the same principle named earlier in this series a boundary is a guarantee, not a limitation, pushed one level deeper. Not just where CSS ends and JavaScript begins, but what CSS refuses to become while staying entirely inside its own domain.

Demonstrating the Principle

--spacing-md: 1rem;
--is-modal-open: 1;

Identical syntax. Identical validity, as far as the browser is concerned. One is a value. The other is application state, wearing a token's clothing, because nothing about the platform distinguishes them and nothing about the system's design decided to. The browser will never refuse this. The refusal has to come from a decision made in advance not a limitation the platform hands anyone for free.

quell as the Case Study

quell's token layer holds values, and only values. Not because the platform enforces it, but because the system decided, in advance, not to let anything resembling state or logic live there.

The Broader Lesson

The strongest systems, in software and well outside it, are usually defined as much by what they've declared they won't do as by what they can. "What should this never do" is a harder question than "what should this do," precisely because it asks for a decision made in advance, one that convenience will keep quietly tempting someone to break later.

That's the difference between a system that merely works today and one built to still make sense after the person who wrote it is no longer the one answering questions about it.

Notas de campo: la resolución de la cascada, de principio a fin

Franklin — Sat, 22 Aug 2026 11:41:28 +0000

El artículo del jueves describió el orden en que el navegador resuelve los conflictos de CSS: primero origen e importancia, luego el orden de las capas, después la especificidad y, por último, el source order, con la herencia por debajo de todo. Describir un orden es una cosa. Verlo funcionar en un conflicto real es otra. Esto es eso.

También disponible en Inglés

La preparación (The Setup)

Un botón. Seis declaraciones. Todas compiten por la misma propiedad, abarcando cada etapa de la secuencia de resolución:

/* UA stylesheet — browser default */
button { color: buttontext; }

/* Author, @layer base (declared first) */
@layer base {
  .btn { color: black; }
}

/* Author, @layer utilities (declared after base) */
@layer utilities {
  .text-blue { color: blue; }
}

/* Author, unlayered */
#submit { color: red; }

/* Author, !important */
@layer base {
  .btn { color: purple !important; }
}

/* User stylesheet — e.g. a browser accessibility override */
button { color: green !important; }

<button id="submit" class="btn text-blue">Submit</button>

¿Qué color gana?

Etapa uno: Origen e importancia

Esta etapa se comprueba antes de consultar cualquier otra regla de la lista y termina el conflicto de inmediato: gana el color verde (green).

No ocurre por ser el selector más específico. No lo es; un selector simple como button es tan poco específico como se pueda imaginar. Gana porque un !important con origen de usuario (user-origin) supera a un !important con origen de autor (author-origin). Es el único punto donde la lógica habitual el autor supera al usuario se invierte.

Cabe preguntarse por qué la plataforma está construida así. La razón es breve y sólida: el usuario a veces necesita una forma de sobrescribir los estilos del autor que le perjudican. Un sitio que define un texto demasiado pequeño para leerse, o una combinación de colores que no cumple con sus necesidades de contraste. Si el !important del autor siempre superara al !important del usuario, esa sobrescritura sería imposible de aplicar, sin importar la configuración del navegador o de la tecnología de asistencia. Los ajustes de accesibilidad deben mantener su autoridad. Por eso la cascada otorga la última palabra al !important de usuario, específicamente para garantizar que esa regla se cumpla.

No es un caso extremo oculto en la especificación. Es la razón de ser de esta etapa del algoritmo.

Etapa dos: Orden de capas (Layer Order)

Elimina las dos declaraciones !important la sobrescritura del usuario y la del autor y observa lo que queda: cuatro declaraciones de importancia normal, distribuidas en la hoja de estilo del agente de usuario (UA stylesheet), dos capas de autor (authored layers) y una regla sin capa (unlayered).

El orden de las capas resuelve esto antes de llegar a la especificidad. La regla sin capa #submit { color: red; } supera a cualquier regla con capa, sin condiciones. Los estilos sin capa siempre ganan a los estilos con capa, sin importar cuán pesado o ligero sea el selector dentro de ella. El color rojo (red) gana esta ronda.

Deja de lado la regla sin capa por un momento. La comparación se vuelve más interesante: .btn en base contra .text-blue en utilities. utilities se declaró después de base, por lo que .text-blue habría ganado. No porque el color azul (blue) tenga un selector más específico que el negro (black) no es así, ambos son clases individuales, sino porque la capa en la que reside se declaró más tarde. Este es el mecanismo exacto descrito en el artículo sobre Cascade Layers, operando ahora frente a otras etapas reales en lugar de analizarse de forma aislada.

Etapa tres: Source Order, en aislamiento

Simplifica el ejemplo una vez más. Misma capa, misma especificidad, dos declaraciones que solo difieren en cuál aparece más abajo en el archivo:

@layer base {
  .btn { color: black; }
  .btn { color: navy; }
}

El color azul marino (navy) gana. No había nada más disponible para decidir misma capa, misma especificidad, por lo que el algoritmo cae en la última etapa: la regla que aparece más tarde en el orden del código (source order). Esta es la etapa que el artículo 6 mencionó pero nunca demostró. Aquí está, aislada, haciendo exactamente lo que indica la especificación y nada más.

Lo que esto realmente demuestra

Seis declaraciones. Cinco etapas distintas de una sola secuencia. Cada una solo se consulta porque las anteriores no lograron producir una decisión. En el momento en que el origen y la importancia resolvieron el ejemplo externo, las capas, la especificidad y el source order no fueron consultados. Resultaron irrelevantes en el instante en que el color verde (green) ganó. Esa es la estructura real del algoritmo: no una secuencia de desempate, sino una serie de compuertas de eliminación. La mayoría de los conflictos nunca superan la primera compuerta aplicable.

Field Notes: Watching the Cascade Resolve, Start to Finish

Franklin — Sat, 22 Aug 2026 11:39:45 +0000

Thursday's piece described the order the browser resolves conflicting CSS in: origin and importance first, then layer order, then specificity, then source order, with inheritance underneath all of it. Describing an order is one thing. Watching it actually run, on a real conflict, is another. This is that.

Also available in Español

The Setup

One button. Six declarations, all fighting over the same property, spanning every stage of the resolution sequence:

/* UA stylesheet — browser default */
button { color: buttontext; }

/* Author, @layer base (declared first) */
@layer base {
  .btn { color: black; }
}

/* Author, @layer utilities (declared after base) */
@layer utilities {
  .text-blue { color: blue; }
}

/* Author, unlayered */
#submit { color: red; }

/* Author, !important */
@layer base {
  .btn { color: purple !important; }
}

/* User stylesheet — e.g. a browser accessibility override */
button { color: green !important; }

<button id="submit" class="btn text-blue">Submit</button>

Which color wins?

Stage One: Origin and Importance

This stage is checked before anything else on the list is even consulted, and it ends the conflict immediately: green wins.

Not because it's the most specific selector. It isn't button alone is about as unspecific as a selector gets. It wins because user-origin !important outranks author-origin !important, which is the one place the usual assumption author beats user inverts.

Worth asking why the platform is built this way at all, because the reasoning is short and solid: a user sometimes needs a way to override author styles that work against them a site that sets text too small to read, or a color combination that fails their contrast needs. If author !important could always beat user !important, that override would be permanently unenforceable, no matter how the user's browser or assistive technology was configured. Accessibility settings need to stay authoritative. So the cascade gives user !important the final word, specifically so that guarantee holds.

That's not an edge case buried in the spec. It's the entire reason this stage of the algorithm exists.

Stage Two: Layer Order

Remove the two !important declarations the user override and the author override and look at what's left: four normal-importance declarations, spread across the UA stylesheet, two authored layers, and one unlayered rule.

Layer order settles this before specificity is ever reached. The unlayered #submit { color: red; } beats every layered rule, unconditionally unlayered styles always win over layered ones, regardless of how heavy or light the selector inside a layer happens to be. red wins this round.

Set the unlayered rule aside for a moment, and the comparison gets more interesting: .btn in base versus .text-blue in utilities. utilities was declared after base, so .text-blue would have won not because blue has a more specific selector than black (it doesn't; both are single classes), but because the layer it lives in was declared later. This is the exact mechanism from the Cascade Layers piece, now running against real other stages instead of standing on its own.

Stage Three: Source Order, in Isolation

Strip the example down one more time same layer, same specificity, two declarations differing only in which one appears later in the file:

@layer base {
  .btn { color: black; }
  .btn { color: navy; }
}

navy wins. Nothing else was available to decide it same layer, same specificity so the algorithm falls through to the last stage: whichever rule appears later in source order. This is the stage article 6 named but never demonstrated. Here it is, isolated, doing exactly what it's specified to do and nothing more.

What This Actually Shows

Six declarations. Five different stages of one sequence, each one only getting consulted because everything before it failed to produce a decision. The moment origin and importance settled the outer example, layers, specificity, and source order never got asked anything at all they were irrelevant the instant green won. That's the real shape of the algorithm: not a tiebreaker sequence, but a series of gates. Most conflicts never make it past the first one that actually applies.

El navegador ya tiene una arquitectura. La mayoría de los proyectos la ignoran.

Franklin — Thu, 20 Aug 2026 10:50:29 +0000

También disponible en Inglés

El problema

Pregunta a la mayoría de los desarrolladores cómo funciona la especificidad; sabrán explicarlo. Pregunta sobre la herencia; también sabrán explicarla. El orden de declaración, el origen, !important — casi todo esto se aprende por separado, por lo general al depurar un error, y se olvida en cuanto se apaga el incendio inmediato.

Casi nadie los aprende como un solo sistema.

El cambio de perspectiva que importa es este: el navegador no tiene seis datos de CSS inconexos dispersos en su motor de renderizado. Tiene un algoritmo completo y especificado para la resolución de la cascada; una respuesta real y ordenada a la pregunta "qué regla se aplica aquí", resuelta etapa por etapa. La mayoría de los proyectos nunca han leído ese algoritmo de principio a fin. Solo se han encontrado con él ante un diseño roto.

Por qué existe el problema

Estos mecanismos se enseñan por partes, porque así es como se necesitan. Un tutorial explica la especificidad porque la especificidad acaba de dar un problema a alguien. Una respuesta en Stack Overflow explica la herencia porque el tamaño de la fuente de alguien no se comportaba como debía. Cada explicación es precisa, acotada y está desconectada de las otras cinco etapas del mismo algoritmo que operan justo al lado.

Es una forma rápida de corregir un error. Es una mala forma de aprender un sistema. Un equipo puede entender la especificidad a fondo y, aun así, no saber que el origen, la importancia y el orden de las capas se resuelven antes de consultar la especificidad. Esto significa pasar horas luchando una batalla de especificidad que ya se había perdido, o ganado, en una etapa anterior que nadie pensó en verificar. Cuando esto ocurre con frecuencia, los equipos dejan de confiar en la cascada. En su lugar, construyen una arquitectura paralela encima de ella —convenciones de nomenclatura, herramientas de scoping, capas adicionales de abstracción— para resolver problemas que el propio algoritmo del navegador ya resuelve. Solo que no lo hace de manera visible, porque nadie leyó la secuencia completa.

El primer principio

Este es el orden real, presentado como una secuencia en lugar de un glosario de términos independientes.

El origen y la importancia se comprueban primero: estilos del navegador, estilos del autor, estilos del usuario y si !important está aplicado a alguno de ellos. Después, el orden de las capas (@layer) para cualquier declaración dentro de ellas; aunque cabe destacar que !important invierte este orden, haciendo que gane la primera capa declarada en lugar de la última. Luego se evalúa la especificidad, pero solo entre las reglas que sobrevivieron sin resolverse a las dos primeras etapas. Finalmente, el orden de declaración funciona como desempate cuando nada más lo ha solucionado. La herencia se ejecuta por debajo de toda la secuencia, proporcionando en silencio una respuesta para cualquier propiedad que los pasos anteriores no hayan abordado.

El cambio de perspectiva: nunca fueron cinco datos para memorizar por separado. Es un solo algoritmo ordenado, y cada una de esas palabras familiares (origen, capas, especificidad, orden de declaración, herencia) nombra una fase dentro de él. Aprendidos de forma aislada, son datos de trivia. Aprendidos como una secuencia, constituyen un contrato de ingeniería sobre el cual un equipo puede diseñar a propósito.

Demostración del principio

Una regla dentro de una capa con alta especificidad aún puede perder frente a una regla sin capa con mucha menos especificidad. No es un error; es la secuencia funcionando según lo especificado. El orden de las capas se resuelve antes de llegar a la especificidad. Para estilos normales, las reglas sin capa tienen prioridad sobre todas las capas explícitas, ganando independientemente de la especificidad. Para estilos con !important, esa prioridad se invierte, otorgando la ventaja a las reglas con capa. Conocer dónde se sitúan las capas en la secuencia en relación con el origen y la importancia marca la diferencia entre una sobrescritura inesperada y un sistema de diseño predecible.

quell como caso de estudio

La arquitectura de quell se mantiene de forma fiable en producción por una razón sencilla: fue diseñada con este orden de resolución completo en mente desde el principio, no armada mediante prueba y error contra reglas aisladas aprendidas de una en una.

La lección general

La mayoría de los problemas de ingeniería que parecen deberse a la falta de características son, en realidad, falta de comprensión de un sistema que ya se había proporcionado. El navegador no falló al darle una arquitectura a CSS. Proporcionó una completa, especificada, estable y estandarizada, y la mayoría de los proyectos construyen en silencio una segunda arquitectura informal encima de ella, porque la primera nunca se leyó en su totalidad.

Ese patrón no es exclusivo de CSS. Aparece en cualquier lugar donde un sistema se aprende en piezas desconectadas en lugar de como la secuencia única que realmente es: reinventar lo que ya existe, a un costo real, porque nadie se sentó a leer el conjunto de principio a fin.

The Browser Already Has an Architecture. Most Projects Ignore It.

Franklin — Thu, 20 Aug 2026 10:49:19 +0000

Also available in Español

The Problem

Ask most developers to explain specificity, and they can. Ask about inheritance, and they can explain that too. Source order, origin, !important — most of these get learned individually, usually while debugging something that broke, usually forgotten again once the immediate fire is out.

Almost nobody learns them as one system.

Here's the reframe that actually matters: the browser doesn't have six unrelated CSS facts scattered around its rendering engine. It has a complete, specified cascade resolution algorithm, an actual, ordered answer to "which rule applies here," worked out stage by stage. Most projects have never read that algorithm end to end. They've only ever met it one broken layout at a time.

Why the Problem Exists

These mechanisms get taught piecemeal, because that's how they get needed. A tutorial explains specificity because specificity is the thing that just bit someone. A Stack Overflow answer explains inheritance because someone's font size wasn't behaving. Each explanation is accurate, narrow, and disconnected from the five other stages of the same algorithm sitting right next to it.

That's an efficient way to patch one bug. It's a poor way to learn a system. A team can understand specificity in real depth and still not realize that origin, importance, and layer order all get resolved before specificity is ever consulted — which means hours can be spent fighting a specificity battle that was already lost, or won, at an earlier stage nobody thought to check. When that happens enough times, teams stop trusting the cascade at all. They build a parallel architecture on top of it instead — naming conventions, scoped tooling, extra layers of abstraction — to solve problems the browser's own algorithm already resolves, just not visibly, because nobody read the whole thing as one sequence.

The First Principle

Here's the actual order, laid out as a sequence rather than a glossary of separate terms.

Origin and importance are checked first: browser styles, author styles, user styles, and whether !important is attached to any of them. Then layer order, for anything declared inside @layer — though worth knowing, !important flips that order, so the first declared layer wins instead of the last. Then specificity, but only among rules that have already survived the first two stages unresolved. Then source order, as the final tiebreaker when nothing else has settled it. Inheritance runs underneath the entire sequence, quietly supplying an answer for any property none of the above ever addressed.

The reframe: this was never six facts to memorize separately. It's one ordered algorithm, and each of those familiar words (origin, layers, specificity, source order, inheritance) names a single stage inside it. Learned in isolation, they're trivia. Learned as a sequence, they're an engineering contract a team can design against on purpose.

Demonstrating the Principle

A layered rule with high specificity can still lose to an unlayered rule with far less specificity and that's not a bug, it's the sequence working as specified. Layer order is resolved before specificity is ever reached. For normal styles, unlayered rules sit above all explicit layers in precedence, winning over layered rules regardless of specificity. For !important styles, that priority flips, giving layered rules the advantage. Knowing where layers sit in the sequence relative to origin and importance is the difference between an unexpected override and a predictable design system.

quell as the Case Study

quell's architecture holds up reliably in production for a plain reason: it was designed with this full resolution order in view from the start, not assembled by trial and error against isolated rules learned one at a time.

The Broader Lesson

Most engineering problems that feel like missing features are actually missing understanding of a system that was already provided. The browser didn't fail to give CSS an architecture. It gave one, fully specified, stable, standards-track, and most projects quietly build a second, informal one on top of it, because the first one was never read as a whole.

That pattern isn't unique to CSS. It shows up anywhere a system gets learned in disconnected pieces instead of as the single sequence it actually is: reinventing what's already there, at real cost, because nobody ever sat down and read the whole thing end to end.

Las capas de cascada no reemplazaron la especificidad. Reemplazaron la negociación.

Franklin — Tue, 18 Aug 2026 12:06:06 +0000

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

Cascade Layers Didn't Replace Specificity — They Replaced Negotiation

Franklin — Tue, 18 Aug 2026 12:04:07 +0000

Also available in Español

The Problem

The last piece ended on a promise: a real mechanism for boundaries exists, native to the browser, no build step required.

Most explanations of that mechanism describe it as a specificity tool — a way to write weaker selectors and still win the conflict. That's true. It's also the shallow read.

Here's the deeper one. Before Cascade Layers, styling conflicts on any team of real size eventually got resolved the same way: people talked to each other. Someone asked whether it was safe to override the button styles, and word came back from whoever remembered the last time that broke something. A senior engineer settled an argument about whose selector should win, informally, in a thread nobody else will ever find again. That's negotiation. And negotiation is what actually broke down at scale — long before any individual selector did.

Why the Problem Exists

Negotiation-based precedence looks reasonable when a handful of people hold all the context in their heads. "We don't use IDs." "Don't touch that file without asking first." "Check with Sarah before overriding anything in components." Rules like these work exactly as long as the people who made them are still in the room, still remembering, still available to be asked.

They don't survive growth, turnover, or the ordinary passage of time — which is the same entropy mechanism named earlier in this series, resurfacing here in social form instead of code form. Specificity, in this light, wasn't really the battlefield. It was the proxy: the place where unresolved disagreements about ownership and intent got fought out, selector by selector, because there was nowhere else for that disagreement to live.

The First Principle

Here's the shift worth naming precisely: Cascade Layers don't just add a new precedence rule. They replace a social mechanism with a declared one.

@layer theme, tokens, base, layout, components, interactive, utilities, overrides;

One line. Stated once. Enforced by the browser afterward, with no exceptions and nothing left for anyone to remember, ask, or negotiate again. Order stops being tribal knowledge, passed down through onboarding conversations and Slack history. It becomes source code — visible, versioned, and true for every contributor whether or not they were ever in the room where the original agreement was made.

Demonstrating the Principle

@layer components, utilities;

@layer components {
  .card .title { font-size: 1.25rem; }
}

@layer utilities {
  .text-lg { font-size: 2rem; }
}

.text-lg wins. Not by writing a heavier selector or escalating to !important — nobody had to ask permission first, either. The order was already settled before either rule was written, because it was declared, once, at the top of the file.

quell-base.css as the Case Study

quell-base.css is the real, shipping foundation this thesis is built on. It declares five layers, in this exact order:

@layer ghost_tokens, reset, baseline, forms, utilities;

Each layer doesn't just own a category of styling — it pre-resolves an argument that would otherwise have to be negotiated every time it came up.

ghost_tokens — fully-resolved fallback values, parsed by the browser before the first paint. Settles, in advance, whether a var() call is ever left pointing at nothing while a theme sheet is still loading. No race condition to negotiate, because the fallback was never in question.

reset — browser inconsistency erased, with zero visual opinion. This is article one's exact distinction, enforced as policy rather than argued about later: normalization lives here, and only here, so nobody has to ask whether "reset" secretly means "someone's taste."

baseline — minimal visual design, consuming tokens rather than inventing values of its own. Settles, permanently, that this layer renders decisions made elsewhere; it doesn't make new ones.

forms — form elements isolated into their own surface, normalized apart from everything else. Nobody has to negotiate whether a <button> reset belongs in the same conversation as an <input> reset; the boundary is already drawn.

utilities — intentionally empty in the core file, reserved and highest-priority by declaration. Whatever a downstream team appends here will beat every layer above it, automatically, because that was decided in advance and not left for someone to win later with a heavier selector.

None of this required a meeting. None of it requires the original author to still be on the team for it to keep working — which the file states almost as a guarantee of its own: three explicit override surfaces, ranked in ascending power. Redeclare a token on :root, outside any layer, and it wins. Reopen @layer baseline {} in a downstream sheet, and the append lands exactly where intended. Write an unlayered rule at all, and it beats every layer listed above it, unconditionally. The file's own words for what that buys: "No !important required."

The agreement is the architecture now, not a memory a handful of people are responsible for keeping alive.

The Broader Lesson

Any team, of any size, eventually needs a way to resolve conflicting claims to authority. Most systems, in code or out of it, default to negotiation: whoever's most senior in the room, or simply most insistent in the moment, wins. That approach feels natural because it's how most human systems start. It also doesn't scale, and it doesn't survive the departure of the people who built it.

Declared, enforced order does survive. That's what Cascade Layers actually replaced — not a weaker selector, but a negotiation nobody wanted to keep having: architecture is what lets an agreement outlive the meeting where it was made.

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

Franklin — Thu, 13 Aug 2026 11:05:46 +0000

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

CSS Doesn't Need More Power — It Needs Better Boundaries

Franklin — Thu, 13 Aug 2026 11:05:12 +0000

Also available in Español

The Problem

A team hits a styling problem that CSS won't cooperate with. Something needs to change based on a click, a scroll position, a piece of application state. So they reach for more power.

A heavier selector. An !important. Sometimes CSS gets skipped entirely — element.style.display = 'none', set directly from a click handler, because it felt more reliable than trusting the cascade to do what was asked.

None of the last three problems in this series were solved by giving CSS more capability. Resets weren't broken by CSS being too weak to normalize browsers — they were broken by opinion and normalization sharing a boundary that should never have been shared. Specificity wasn't broken by selectors being too weak — it was broken by having no way to declare intent independent of selector weight. Entropy wasn't caused by CSS lacking some feature — it was caused by nothing marking the boundary between what's safe to remove and what isn't.

Every one of those was a boundary problem. Not one of them was a power problem.

Why the Problem Exists

CSS earned its reputation for unpredictability honestly — that's the last three articles. And the natural response to something unpredictable is to route around it. JavaScript is right there. Imperative, powerful, willing to set exactly the value you want on exactly the element you want, the instant you want it.

But every line of presentation logic that moves into JavaScript is a line the cascade can no longer see or reason about. It's now a value competing with real CSS rules, in ways specificity was never built to arbitrate and layers, once they're introduced, won't be able to see either. The unpredictability doesn't get fixed. It gets relocated somewhere even less structured — spread across click handlers and component lifecycles instead of contained in one stylesheet where at least the problem was visible.

The First Principle

A boundary is not a limitation. It's a guarantee.

CSS already owns four things outright, with real browser-granted authority: presentation, transition, layout, rendering. That's not a small list — the browser hands CSS genuine control over how nearly everything on a page looks and moves. The undersold fact is that this is already enough. The instinct to reach past CSS for more power isn't usually because CSS lacks capability inside its actual job. It's because the edges of that job were never explicitly drawn.

CSS shouldn't own application state. It shouldn't encode business logic. The moment either of those creep in — a class name that secretly represents a data value, a selector chosen based on what the backend returned rather than what the element is — the guarantee breaks. And it doesn't just break for the person who wrote the crossing. It breaks for everyone who touches that code afterward, because now presentation can no longer be trusted to live in exactly one place.

Demonstrating the Principle

One toggle, done two ways.

Set directly from a click handler:

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

Or the same interaction, with the boundary intact — JavaScript changes state, CSS owns the resulting presentation:

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

.panel {
  display: none;
}

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

Same outcome, from the user's side. But in the second version, presentation stays fully legible from the stylesheet alone. Nobody has to go hunting through JavaScript to understand how .panel behaves.

quell as the Case Study

quell draws this boundary explicitly, and treats it as non-negotiable: CSS owns presentation, JavaScript owns behavior, HTML owns structure. Nothing in the system is permitted to quietly cross that line — a rule enforced by convention as firmly as it's enforced by architecture.

The Broader Lesson

This closes the first four pieces of this series, and it's worth naming the shape underneath all of them.

Resets: something claiming neutrality that wasn't neutral. Specificity: something calculating that should have been declaring. Entropy: something growing that should have been governable. And now this: something reaching for power when what it actually needed was a line nobody had drawn yet.

Four different symptoms. One underlying fix, named plainly for the first time here: boundaries, not power. The rest of this series exists to show exactly how the browser lets you build boundaries for real — starting with the mechanism that gives the cascade an explicit ordering axis of its own.

Por qué toda hoja de estilos grande termina siendo impredecible

Franklin — Tue, 11 Aug 2026 11:02:10 +0000

También disponible en English.

El problema

Cada equipo hereda una hoja de estilos así, tarde o temprano.

No está mal escrita. Nadie en el equipo original fue descuidado. Los selectores son razonables. El nombramiento es lo suficientemente consistente. Y aun así, nadie la toca sin miedo, porque nadie está seguro de cuáles de sus cuatro mil líneas son estructurales.

Así que el instinto es siempre el mismo. Añadir una regla nueva. No eliminar la vieja — por si acaso. Un componente nuevo recibe su propio selector en lugar de reutilizar algo en lo que, de alguna manera, se podría estar confiando en otro lugar de formas que nadie documentó. El archivo crece. Nunca se reduce. No porque alguien decidiera que solo debería crecer — sino porque crecer se sentía seguro y reducirse nunca lo fue.

Por qué existe el problema

Eliminar una regla requiere confianza. Añadir una no requiere ninguna.

Esa asimetría es todo el mecanismo. El CSS es aditivo y permisivo por naturaleza — escribes una regla nueva y simplemente funciona, superpuesta a todo lo que vino antes, sin romper nada más en el proceso. Esa es una fortaleza genuina. También es exactamente por lo que nadie se siente seguro restando. Borrar una regla significa demostrar que nada depende de ella, en cada página, cada componente, cada ancho de navegador, cada estado — y el CSS no ofrece una forma fácil de demostrar eso.

Así que se escriben selectores defensivos no porque se necesiten hoy, sino porque un desarrollador no está seguro de qué se rompe si simplemente confía en lo que ya está ahí. Las reglas muertas sobreviven indefinidamente, porque nada en el sistema le dice a nadie que están muertas.

El intercambio tiene la misma forma que los dos últimos problemas de esta serie, con una cara diferente: la misma cualidad que hace al CSS accesible —siempre puedes simplemente añadir más— es la cualidad que hace que las hojas de estilos grandes sean ingobernables con el tiempo.

El primer principio

Nómbralo claramente: el CSS no tiene un bucle de retroalimentación para la irrelevancia.

Un lenguaje compilado marca una variable no utilizada. Una importación no utilizada recibe una advertencia, a veces un error. Las herramientas le dicen al autor, directamente: "esto no está haciendo nada — elimínalo". El CSS no tiene nada equivalente integrado en el propio lenguaje. Una regla que deja de importar no se anuncia. Simplemente se queda ahí, permanentemente ambigua — tal vez estructural, tal vez vestigial, indistinguible desde fuera, para siempre.

Los equipos no crean este tipo de entropía por descuido. La crean porque el sistema nunca les dice cuándo es realmente seguro eliminar algo. Con suficiente tiempo y suficientes colaboradores, ese silencio se acumula. No por la negligencia de nadie — sino por la simple y repetida ausencia de una señal que nunca existió.

Demostración del principio

Un solo ejemplo silencioso lleva esto más lejos que un catálogo.

En algún lugar de una hoja de estilos real: una regla apuntando a .legacy-card-footer. La plantilla que usaba esa clase fue reconstruida hace ocho meses. Nadie eliminó la regla, porque nadie pudo demostrar, rápidamente, que nada más la referenciaba. Así que se sigue enviando. A cada visitante. En cada carga de página. Sin hacer nada, indefinidamente, porque borrarla se sentía más arriesgado que dejarla - y la propia hoja de estilos no ofrecía forma de notar la diferencia.

quell como estudio de caso

Los límites de capa explícitos no hacen que el código muerto sea imposible. Lo hacen localizable. Una regla obsoleta dentro de componentes es un problema mucho más pequeño y fácil de buscar que una regla obsoleta enterrada en algún lugar de un archivo global indiferenciado, sin límites que digan siquiera por dónde empezar a buscar.

La lección general

La entropía no es un fallo de disciplina. Ni en el CSS, ni en ningún otro lugar.

Es lo que sucede, de forma fiable, siempre que un sistema recompensa la suma y no ofrece nada a cambio de la resta. El arreglo nunca fue "esforzarse más por eliminar cosas" - ese es el mismo instinto de disciplina-como-solución que esta serie ya ha dejado de lado dos veces. El arreglo es construir un sistema donde eliminar sea exactamente tan seguro, y exactamente tan visible, como siempre lo fue añadir.

Ese es el hilo que recorre los tres artículos hasta ahora. No es una serie de quejas de CSS no relacionadas - es una forma recurrente, que se presenta de manera distinta cada vez: un sistema sin arquitectura eventualmente pedirá a la disciplina que haga un trabajo para el que la disciplina nunca fue construida.

Why Every Large Stylesheet Eventually Becomes Unpredictable

Franklin — Tue, 11 Aug 2026 11:01:27 +0000

Also available in Español

The Problem

Every team inherits a stylesheet like this eventually.

Not badly written. Nobody on the original team was careless. Selectors are reasonable. Naming is consistent enough. And still, nobody touches it without dread, because nobody's sure which of its four thousand lines are load-bearing.

So the instinct is always the same. Add a new rule. Don't remove the old one — just in case. A new component gets its own selector rather than reusing something that might, somehow, be relied on elsewhere in ways nobody documented. The file grows. It never shrinks. Not because anyone decided it should only grow — because growing felt safe, and shrinking never did.

Why the Problem Exists

Removing a rule requires confidence. Adding one requires none.

That asymmetry is the whole mechanism. CSS is additive and forgiving by nature — write a new rule, and it just works, layered on top of everything that came before it, without breaking anything else in the process. That's a genuine strength. It's also exactly why nobody ever feels safe subtracting. Deleting a rule means proving nothing depends on it, across every page, every component, every browser width, every state — and CSS gives no easy way to prove that. So defensive selectors get written not because they're needed today, but because a developer isn't sure what breaks if they simply trust what's already there. Dead rules survive indefinitely, because nothing in the system ever tells anyone they're dead.

The trade-off is the same shape as the last two problems in this series, wearing a different face: the very quality that makes CSS approachable — you can always just add more — is the quality that makes large stylesheets ungovernable over time.

The First Principle

Naming it plainly: CSS has no feedback loop for irrelevance.

A compiled language flags an unused variable. An unused import gets a warning, sometimes an error. The tooling tells the author, directly, "this isn't doing anything — remove it." CSS has nothing equivalent built into the language itself. A rule that stops mattering doesn't announce itself. It just sits there, permanently ambiguous — maybe load-bearing, maybe vestigial, indistinguishable from the outside, forever.

Teams don't create this kind of entropy through carelessness. They create it because the system never tells them when it's actually safe to remove something. Given enough time and enough contributors, that silence compounds. Not through anyone's negligence — through the simple, repeated absence of a signal that never existed.

Demonstrating the Principle

A single, quiet example carries this further than a catalog would.

Somewhere in a real stylesheet: a rule targeting .legacy-card-footer. The template that used that class was rebuilt eight months ago. Nobody removed the rule, because nobody could prove, quickly, that nothing else referenced it. So it still ships. To every visitor. On every page load. Doing nothing, indefinitely, because deleting it felt riskier than leaving it — and the stylesheet itself offered no way to tell the difference.

quell as the Case Study

Explicit layer boundaries don't make dead code impossible. They make it findable. A stale rule sitting inside components is a much smaller, more searchable problem than a stale rule buried somewhere in one undifferentiated global file with no boundary telling you where to even start looking.

The Broader Lesson

Entropy isn't a discipline failure. Not in CSS, not anywhere else.

It's what happens, reliably, whenever a system rewards addition and offers nothing in return for subtraction. The fix was never "try harder to remove things" — that's the same discipline-as-solution instinct this series has already set aside twice. The fix is building a system where removal is exactly as safe, and exactly as visible, as addition always was.

That's the thread running under all three articles so far. Not a series of unrelated CSS complaints — one recurring shape, worn differently each time: a system with no architecture will eventually ask discipline to do a job discipline was never built for.