Architecting density themes with tokens

WHAT THIS TESTS Whether you can express a cross-cutting visual dimension like density purely through token indirection and CSS custom property cascading, avoiding per-variant style duplication.

A GOOD ANSWER COVERS Make components consume semantic spacing and sizing tokens, for example space-component-padding or control-height, rather than literal pixels. Define density as a theme that supplies a different set of values for those spacing tokens; compact maps them to smaller values, comfortable to larger. Implement at runtime with CSS custom properties scoped to a wrapper or a data-density attribute, so changing the attribute on a container redefines the variables and the cascade flows new spacing into every descendant component without re-rendering or new stylesheets. Components written against the variables need no per-density code. Keep type and color tokens independent so density composes with light or dark theming. Optionally allow local density scopes for dense regions like data tables.

COMMON WRONG ANSWERS Creating separate stylesheets or component variants per density, which multiplies maintenance. Hardcoding pixel padding so density cannot cascade. Forking each component. Coupling density to color theme. Using JS to set inline styles per element instead of letting CSS variables cascade.

LIKELY FOLLOW-UPS How do CSS custom properties enable the cascade? How do you scope density to one region? How does density compose with light or dark themes? How do you handle components needing nonlinear density adjustments?

ONE CONCRETE EXAMPLE A Button uses padding from var space-button-padding. The comfortable theme sets that variable to a larger value, compact to a smaller one, applied via a data-density attribute on a container. Setting data-density to compact on a toolbar shrinks padding on every control inside it instantly, with no Button-specific compact stylesheet and no change to the Button code.