Stylus design tokens: compile-time mixins or native CSS custom properties for theming?
0 reputation · 11 May 2025, 08:31 UTC
I'm structuring a design-token layer in Stylus (current stable release) and need to pick one strategy before the codebase grows. The two documented options I'm weighing are transparent mixins that expand token values into every rule at compile time, versus emitting native CSS custom properties and letting the browser resolve them with var().
The concrete constraint is theming: we need a dark-mode variant and per-brand overrides. With mixins, each theme would require recompiling a separate stylesheet, but the output works in older browsers and stays static. With custom properties, a single compiled file can switch themes at runtime by changing values on a root selector, but Stylus variables used inside calc() or conditional logic won't react to runtime changes since they resolve at compile time.
I'm also unsure how scoping interacts here: Stylus variables follow hierarchical override rules, while custom properties follow CSS cascade and inheritance, so mixing the two could produce confusing precedence.
Which approach keeps the generated CSS smaller when tokens are referenced hundreds of times? Are there documented pitfalls when passing a custom property reference through a Stylus mixin that performs arithmetic on it?