A guide to providing semantic aliases for colors.
Referencing color scales by their actual scale name can work well, like blue and red. But often, creating semantic aliases like accent, primary, neutral, or brand can be helpful, especially when it comes to theming.
With this approach, you will likely run into issues where you need to use the same scale for multiple semantics. Common examples include:
yellow to "warning", you might also need yellow to communicate "pending".red to "danger", you might also need red to communicate "error" or "rejected".green to "success", you might also need green to communicate "valid".blue to "accent", you might also need blue to communicate "info".In this scenario, you can choose to define multiple semantic aliases which map to the same scale.
Or you can simply recommend that your teammates defer to the original scale name for situations where there is no appropriate semantic alias.
Each step in Radix Colors scales is designed for a specific use case. To help your team know which step to use, you can provide aliases based on the designed use cases.
Again, with this approach, you will likely run into issues where you need to use the same step for multiple use cases. Common examples include:
In these cases, you can choose to define multiple aliases which map to the same step.
Or you can simply recommend that your teammates defer to the original step number for situations where use cases don't have an alias.
When designing for both light and dark modes, you sometimes need to map a variable to one color in light mode, and another color in dark mode. Common examples include:
Avoid using specific variable names like "CardBg", or "Tooltip", because you will likely need to use each variable for multiple use cases.
If you wish, you can rename scales. Reasons might include:
gray to keep things simple.sky or grass to blue or green to keep the naming intuitive.blurple.