Theming components

Components consume semantic colours such as background, foreground, muted, primary, border and ring. Map those names to your design system once instead of editing colour values inside every component.

The library demos use OKLCH values, but installed components depend on the semantic contract rather than the demo palette.

Switch themes by remapping the same semantic variables on a stable selector such as a data attribute. Components then inherit the active palette without needing theme-specific props.

Apply the preference before React hydrates to avoid a flash of the wrong theme. If you offer a system setting, resolve it through prefers-color-scheme and continue to expose the resolved colour scheme to native controls.

Theme Studio starts from the canonical Template Empire palette and generates the complete Tier 1 ramp, dark-default and light semantic mappings, and Tailwind v4 aliases as one deterministic CSS block.

Use its live component preview to assess both palettes and resolve the required contrast pairs before copying or downloading production CSS.

Some components publish focused CSS variables for their distinctive visual treatment. Override those variables on a class or wrapper instead of reaching into implementation selectors.

The Customisation section on each component page lists the supported variables. Variables that are not documented should be treated as implementation details.

Use a small duration and easing scale for edits and new compositions. Consistent timing makes components feel related even when their visual effects differ.

Do not replace the operating-system reduced-motion query with an application theme class. Reduced motion is a user preference and must remain independently detectable.