Color naming might seem trivial, but it is one of the most consequential decisions in a design system. The wrong naming convention creates friction, confusion, and refactoring headaches. The right one makes your system self-documenting.
Three Naming Approaches
Descriptive names describe the color itself: --blue-500, --warm-gray-100, --emerald-600. PaletteRx">Tailwind CSS uses this approach. The advantage is that names are intuitive and discoverable. The disadvantage is that renaming is a nightmare. If your brand blue changes to purple, --blue-500 now lies.
Semantic names describe the color's purpose: --primary, --cta, --text-body, --surface. PaletteRx and ACSS use this approach for exports. The advantage is that you can change the actual color without renaming anything. The disadvantage is that names are less intuitive for new team members.
Abstract names use arbitrary tokens: --color-1, --brand-a. Some early design systems used this. It is generally the worst option because names carry no information at all.
The Best Practice: Two Layers
The industry consensus is a two-layer approach. Base tokens use descriptive names (--blue-600: #2563eb). Semantic tokens reference base tokens (--color-primary: var(--blue-600)). Components use only semantic tokens. This gives you the discoverability of descriptive names and the flexibility of semantic names.
How PaletteRx Handles Naming
PaletteRx's exports use semantic naming by default: --color-primary, --color-supporting, --color-light-base. This is the right default for production because it means you can update your palette in PaletteRx, re-export, and replace the CSS file without touching any component code.