web-styling-theming
Installation
SKILL.md
Runtime Theming Patterns
Quick Guide: Two independent signals decide a theme — the OS preference (
prefers-color-scheme) as the default, and an explicit attribute on<html>as the override that has to win in both directions. The attribute is stamped by a synchronous inline script in<head>before first paint; anything running in an effect flashes on every load. Persist the preference (light | dark | system), never the resolved value, so "system" stays a live subscription to the OS. Themes swap token values under stable role names, one complete block per scope, each declaringcolor-schemeso native UI follows.
Detailed Resources:
- examples/core.md — dual-signal CSS, pre-paint boot script, SSR and cookie theming, the three-state preference module, provider configuration, semantic token switching
- examples/advanced.md — multi-brand axis, nested theme scopes, portal caveats, transition suppression, reduced motion, browser chrome
- reference.md —
next-themesprop and return-value contract, platform feature support, the specificity table
Which path applies
- The OS preference is the whole requirement, with no in-app control — a
prefers-color-schemeblock is the entire job. None of the JavaScript below is needed. - A user-facing choice, in any framework — Patterns 1, 2, 3 and 5 are the complete hand-rolled system: guarded media query, pre-paint script, three-state preference, token blocks. Follow examples/core.md.
- A React app where localStorage is acceptable — a provider library already implements the boot script, the persistence, the live tracking, the cross-tab sync and the transition suppression. Read Pattern 4 for its contract and its one structural limitation, then skip Patterns 2 and 3.
- The server-rendered HTML itself must carry the theme — the preference has to be a cookie, read during the render, because localStorage is unreachable from the server. That rules out the provider libraries, which are localStorage-only.