Component tokens
Define a component’s “mini design system” with custom properties, then create variants by overriding tokens at the boundary — without multiplying classes.
Quick implementation
/* Component boundary: define defaults */
.card {
--card-bg: var(--card);
--card-border: var(--card-border);
--card-title: var(--text);
--card-body: var(--muted);
--card-accent: var(--accent);
background: var(--card-bg);
border: 1px solid var(--card-border);
border-radius: var(--radius-lg);
}
/* Variant: override tokens (no new markup) */
.card--warning {
--card-border: oklch(0.55 0.10 65 / 0.55);
--card-accent: oklch(0.75 0.18 70);
}Prompt this to your LLM
Includes role, constraints, two framework variants, and edge cases to handle.
You are a senior frontend engineer building a component library.
Goal: Implement a card component that uses CSS custom properties as component-level design tokens so variants can be created by overriding variables at the component boundary.
Technical constraints:
- Define default tokens on the component root (e.g. --card-bg, --card-border, --card-title, --card-accent).
- Consume those tokens inside the component styles using var(--token).
- Create at least two variants (e.g. .card--brand and .card--warning) that only override tokens, not structural CSS.
- Keep the token names component-scoped (prefix with card- or a component acronym) to avoid collisions in large codebases.
- Use oklch() for any explicit colors, not hex/rgb/hsl.
Framework variant (pick one):
A) Vanilla CSS + HTML demo showing the same markup with different classes on the root.
B) React: <Card tone="warning" /> that sets style={{'--card-accent': '...'}} on the root.
Edge cases to handle:
- Nested components: ensure child components can define their own token namespace without being overwritten.
- Theming: allow global theme tokens (like --accent) to feed component tokens as defaults.
- Specificity: variants should not require !important.
Return HTML + CSS.Why this matters in 2026
Modern design systems need variants, themes, and “one-off” tweaks without CSS exploding into a matrix of modifier classes. Component tokens turn a component into a small, composable theming surface: override variables on the root, and everything inside updates consistently.
The logic
Custom properties participate in the cascade. By defining a token set on the component root (for example --card-accent) and using it internally, you can change the entire look of the component by overriding a few variables on the same element. This keeps structural CSS stable while variants become data.
Accessibility & performance
Token overrides are purely presentational and don’t affect semantics. For performance, custom properties are computed efficiently and allow theme changes (including runtime toggles) without rebuilding style sheets. Keep token names predictable and avoid overly deep dependency chains to make debugging easier.