A single source of truth for color, type, and spacing means your whole product rethemes from a handful of tokens β€” not a hundred file edits.

Teams ship faster when the preview matches production. Kitchen sinks are useful, but real pages β€” login screens, articles, settings β€” expose gaps that component lists never will.

Start with tokens, not components

Define --accent, --surface, and --radius first. Components become thin wrappers that consume those values. Change the token once; buttons, cards, and nav all shift together.

Most styling bugs are really token bugs. When a button looks wrong on the blog template but fine in the kitchen sink, the component is usually fine β€” the variable mapping is not. A shared .theme scope forces every surface to drink from the same well.

Preview what you ship

Article typography is where themes earn their keep. Headings, pull quotes, inline code, and muted metadata all need distinct roles β€” but they should still feel like one family. If your body font is serif and your UI labels are sans, that contrast should be deliberate, not accidental.

Spacing rhythm matters on long reads. Paragraphs, section breaks, and figure captions should breathe consistently. When --space-unit drives those gaps, tightening or loosening the whole page is a one-slider operation.

Good design systems feel inevitable β€” like the only reasonable way to build.

β€” Someone wise

Export and iterate

Export a standalone theme.css, drop it into any stack, and keep iterating in the browser until it feels right. Share a link with your team, fork a preset, randomize until something surprises you β€” then tune from there.

The goal is not a perfect theme on day one. It is a fast loop: see the whole UI react, adjust one token, feel the shift everywhere. That is the superpower CSS variables give you β€” and why live previews beat static style guides.