A token file is only useful if it makes decisions easier. Most token files make them harder: three blues, four greys that are nearly identical, a spacing scale with no rhythm.
This site uses a deliberately small set.
Two layers
The first layer is raw palette values. They describe colour, not purpose.
:root {
--obsidian: #090909;
--ivory: #e8e0d4;
--crimson: #a51f3d;
--phthalo: #123f35;
--grey: #777777;
}
The second layer is semantic. Components only use these.
:root {
--bg: var(--obsidian);
--text: var(--ivory);
--text-muted: #a29a8e;
--line: rgb(232 224 212 / 0.12);
--accent: var(--crimson);
}
The rule: a component may not reference a raw palette value. If it needs a colour that does not exist semantically, that is a design decision, not a styling decision. Name it first.
Accents belong to context
The seven worlds each have an accent colour. Rather than creating seven sets of semantic tokens, the world layout sets one variable on its root element:
.world-page {
--accent: var(--world-accent);
}
Everything inside — rules, tags, links — inherits the accent without knowing which world it is in. Context is passed down, not hard-coded.
Type is a token too
The type scale is defined with clamp() so it responds to the viewport without breakpoint-specific overrides. The three families are named by role: display, body, mono. A component asks for a role, not a font.
What is deliberately missing
There is no theme switcher. No dark-mode variant. No component-level token aliases. Each of those would add surface area before the design has earned it.
A token system should be boring. Its job is to make the interesting decisions cheaper.