# The Best CSS Architecture Starts by Deciding What CSS Should Never Do > Source: > Published: 2026-08-25 10:34:55+00:00 *Also available in Español* 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. 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. 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. ``` --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'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 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.