Color
Tone-color chips
One base rule derives a chip’s border, fill, and dot from a single --tone-color custom property; variant classes set only that property, so N semantic hues cost one rule to maintain.
Reach for it when building
- category and status badges
- event log entry types
- callout and admonition variants
- label systems in issue trackers
- legend chips beside charts
- color-mix
- badges
- custom-properties
- css-only
<div class="tcc-row">
<span class="tcc-chip tcc-breaking"><i></i>Breaking change</span>
<span class="tcc-chip tcc-fixed"><i></i>Fixed</span>
<span class="tcc-chip tcc-reference"><i></i>Reference</span>
<span class="tcc-chip tcc-series"><i></i>Series</span>
<span class="tcc-chip"><i></i>Note</span>
</div>Colors come from shared theme tokens — --surface, --ink, --border, --accent and friends — so this CSS carries no palette
of its own. Use Runnable file to copy the tokens along with it.
.tcc-row { display: flex; gap: 0.75rem; flex-wrap: wrap; }
/* The entire system: every visual property of the chip derives from
--tone-color at a fixed strength. Variants below only change the hue. */
.tcc-chip {
--tone-color: var(--dim);
display: inline-flex;
align-items: center;
gap: 0.45rem;
font-size: 0.9375rem;
font-weight: 600;
padding: 0.35rem 0.8rem;
border-radius: calc(var(--radius) - 2px);
border: 1.5px solid color-mix(in srgb, var(--tone-color) 50%, transparent);
background: color-mix(in srgb, var(--tone-color) 12%, var(--surface));
color: var(--ink);
}
.tcc-chip i {
width: 0.7rem;
height: 0.7rem;
border-radius: 50%;
background: var(--tone-color);
}
.tcc-breaking { --tone-color: var(--bad); }
.tcc-fixed { --tone-color: var(--ok); }
.tcc-reference { --tone-color: var(--accent); }
.tcc-series { --tone-color: var(--signal); }Paste this into an agent to rebuild the pattern from scratch.
Build a semantic chip system where one CSS rule owns the entire visual treatment and every variant is a single custom-property assignment.
The base chip class declares `--tone-color` with a neutral default, then derives every colored property from it at fixed strengths: the border at 50% via `color-mix(in srgb, var(--tone-color) 50%, transparent)`, the fill at 12% mixed over the surface token, and a small solid dot at full strength. Text stays at the page's ink color — the tone lives in the frame and the dot, never under the words, which is what keeps every variant readable without per-variant contrast checking.
Variant classes then contain exactly one declaration each: `--tone-color: var(--ok)` and nothing else. Adding a new semantic hue is one line; retuning the whole system's strength is one edit to the base rule. Compare that with the usual approach — a border color, background, and icon color hand-written per variant — where the strengths drift apart the third time someone adds one.
Point the tones at the theme's semantic tokens (danger, success, accent, signal), not raw hues, so each chip means one thing everywhere it appears and flips themes for free. Keep the dot: it makes the hue legible even when the 12% fill is too subtle to name, and it gives a colorblind reader a second, denser sample of the same color to judge.
The pattern generalizes past chips — the same one-property contract works for callout boxes, log-row icons, and legend swatches; share the `--tone-color` custom property across all of them and the system stays coherent.
Every color comes from theme custom properties, and every tone must remain distinguishable from the neutral default in both light and dark themes.