Colour — legacy

These are the names the 2020-era design language brought with it, and they sit outside the token architecture rather than at the bottom of it. They still ship and they are still referenced, so nothing here is dead. No new code should reach for one.

What the tier split is, and when it happened

Colour reaches product code through two layers: a primitive is a step on a ramp and says nothing about purpose, and a semantic name says what the primitive is for. That is the split, and the glossary defines both halves of it.

It arrived in three moves, all in 2026:

The names here predate all three. They are not an older spelling of a semantic name and they do not resolve to one: each holds a literal value, a few of them point at each other, and none of them point out of this page. The other direction is empty too — nothing in the primitive or semantic layer reads a name from here. That is what not placed yet meant: nobody has decided which semantic name each of these should become, so no mapping exists in either direction, and one cannot be derived by looking at the values.

Should you use them in new code?

No, and the reason is the theme switch. Every semantic colour changes between light and dark. Not one name on this page does — the dark column below reads same the whole way down, because these were declared years before the app had a second theme and nothing has given them a dark value since. A rule written against one of these names keeps its light-mode colour when a reader switches to dark, on a surface that has moved underneath it.

Nothing will warn you, either. The lint rule that steers people towards semantic tokens reads Tailwind class names in JSX className strings, so a var() naming one of these in a stylesheet passes without a word.

Reach for a semantic name. If none fits, the question to raise is which semantic name is missing — not whether a legacy name will do.

So this is a compatibility layer?

Yes, and a load-bearing one. variables.css is imported by the application entrypoint, so every name here resolves on every page. Hand-written stylesheets under application/ and admin/ — the pre-Tailwind surfaces, including the sign-in pages and the admin tooling — still read them. Deleting a name breaks a real page.

So the retirement path is per use, not per name: when you touch a rule that reads one of these, replace that declaration with the semantic name for the job. The name on this page goes away when its last reader does.