Design tokens are currently single-mode — tokens/colors.json defines flat values (e.g. background: #ffffff, foreground: #171717) with no concept of light/dark. Add dark mode support alongside light, with light mode as the default (matching current values, so no visual regression for existing consumers).
Should:
- Restructure color tokens to support per-mode values (e.g. semantic aliases like
background/foreground resolve differently under light vs. dark) rather than hardcoded single values
- Preserve current light-mode values exactly as today's default/fallback
- Add corresponding dark-mode values for every token that needs one
- Update platform outputs (Tailwind preset, MUI theme, CSS custom properties) to emit both modes and support switching between them
- Cover mode switching in the test suite (
scripts/test.js)
Open question: how consumers select a mode (CSS class/data-attribute toggle, prefers-color-scheme, MUI theme mode prop, etc.) — needs a decision before implementation.
Design tokens are currently single-mode —
tokens/colors.jsondefines flat values (e.g.background: #ffffff,foreground: #171717) with no concept of light/dark. Add dark mode support alongside light, with light mode as the default (matching current values, so no visual regression for existing consumers).Should:
background/foregroundresolve differently under light vs. dark) rather than hardcoded single valuesscripts/test.js)Open question: how consumers select a mode (CSS class/data-attribute toggle,
prefers-color-scheme, MUI theme mode prop, etc.) — needs a decision before implementation.