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

Perfekt CSS begins with an explicit decision about what CSS must never do. The foundation of a design token system starts clean, with colors, spacing, and typography values all equally legitimate. Eventually, someone needs a quick way to track whether a modal is open, and a custom property is there, syntactically identical to the tokens around it.

It's used. Nobody pauses to ask if it should have been used. A stylesheet begins as purely presentational. Then a selector appears, only applying when a user is logged in; a decision that CSS doesn't need to make, coded into CSS nonetheless because that was the path of least resistance at the time. Neither option looks wrong when chosen.

The pattern in both cases is the same: nothing in the system has arguments to say no. Why the problem exists Conversations about architecture almost always begin with the same question: what should this system do. It's a natural, generative question, but there's no natural stopping point. Every capability someone can imagine is a candidate for inclusion, and rarely is there an obvious moment to say no categorically, regardless of how convenient it may be right now.

The result are systems that accumulate default permissions. Restriction only shows up reactively, after something has gone wrong and someone has to write an autopsy explaining how a boolean ended up embedded in a design token. The first principle The absence of explicit exclusions eventually requires a system to do everything, because nothing within it has arguments to deny it.

It's worth stating clearly, because it flips the way most people think about design: exclusions are not the absence of architecture. They are their most resilient part. This principle mentioned earlier in this series: a boundary is a guarantee, not a limitation, taken a step deeper. Not just where CSS ends and JavaScript begins, but what CSS refuses to become while remaining entirely within its own domain.

Demonstrating the principle Identical syntax. Identical validity to the browser. One is a value. The other is application state, dressed as a token, because nothing in the platform distinguishes them and nothing in the system's design decided to make that distinction. The browser will never reject this. Rejection must come from a decision made in advance; not a limitation freely delivered by the platform.

Case study Quill's token layer contains values, and only values. Not because the platform mandates it, but because the system decided in advance not to allow anything that resembles state or logic there. The broader lesson The strongest systems, in both software development and beyond, are often defined by both what they declare they will not do and what they can do.

What this system should not do is a question more challenging than what it should do, precisely because it requires a decision made in advance, one that convenience will silently tempt to break later. That's the difference between a system that simply works today and one built to still make sense after the person who wrote it is no longer the one answering questions about it.