What naming scheme do you use for color variables?
Have you succeeded at writing CSS that uses color variables in a manner agnostic to the colors they represent?
I’ve tried all of the following, and I have yet to succeed at writing CSS that works well with any color scheme. ☹️— Lea Verou (@LeaVerou) October 14, 2018
I remember the very first time I tried Sass on a project. The first thing I wanted to do was variablize my colors. From my naming-things-in-HTML skillz, I knew to avoid classes like .header-blue-left-bottom
because the color and position of that element might change. It’s better for the to reflect it what it is than what it looks like.
So, I tried to make my colors semantic, in a sense — what they represent not what they literally are:
$mainBrandColor: #F060D6;
$secondaryFocus: #4C9FEB;
$fadedHighlight: #F1F3F4;
But I found that I absolutely never remembered them and had to constantly refer to where I defined them in order to use them. Later, in a “screw it” moment, I named colors more like…
$orange: #F060D6;
$red: #BB532E;
$blue: #4C9FEB;
$gray-1: #eee;
$gray-2: #ccc;
$gray-3: #555;
I found that to be much more intuitive with little if any negative side effects. After all, this isn’t crossing the HTML-CSS boundary here; this is all within CSS and developer-only-facing, which puts more of a narrow scope on the problem.
In a similar fashion, I’ve tried keeping colors within a Sass map, like:
$colors: (
light: #ccc,
dark: #333
);
But the only vague goal there was to clean up the global namespace, which probably isn’t worth the hassle of needing to map-get
all the time. Namespacing like $-c-orange
is probably an easier approach if you need to do anything at all.
I’ve largely stuck with that just-use-color-names approach today in Sass. As the shift toward CSS custom properties happens, I think having a --c-orange
and --c-gray-5
is similarly appropriate.
:root {
-c-orange: #F060D6;
-c-red: #BB532E;
-c-blue: #4C9FEB;
-c-gray-1: #eee;
-c-gray-2: #ccc;
-c-gray-3: #555;
}
You could get a little more specific with those names with staying abstract, like Marcus Ortense says:
$color-primary:
$color-primary-dark:
$color-primary-light:
And variations on each base like Mike Street says:
$primary:
$primaryLight:
$primaryDark:
$secondary:
$secondaryLight:
$secondaryDark:
$neutralDarker:
$neutralDark:
$neutral:
$neutralLight:
$neutralLighter:
$neutralLightest:
Silvestar Bistrović recently wrote about using abstract Greek numbering:
$color-alpha: #12e09f;
$color-beta: #e01258;
$color-gamma: #f5f5f5;
$color-psi: #1f1f1f;
$color-omega: #fff;
I’ve used that kind of thing for media query breakpoints before, as the numbering seems to make sense there (i.e. low numbers are smaller screens, big numbers are bigger screens). I could also see that being nice for tints or shades of the same color, but then why not regular numbers?
Another approach I’ve often seen is to combine named colors with abstracted names. Geoff does that and John Carroll lists that here:
$color-danube: #668DD1;
$color-cornflower: $6195ED;
$color-east-bay: $3A4D6E;
// theme1.scss
$color-alpha: $color-danube;
$color-bravo: $color-cornflower;
$color-charlie: $color-east-bay;
// theme2.scss
$color-alpha: $color-cornflower;
$color-bravo: $color-danube;
$color-charlie: $color-east-bay;
That can get as verbose as you need it to, even adding variations as you call from the palette.
$table-row-background: lighten($color-background, 10%);
Stuart Robson even gets a bit BEM-y with the names, including the namespace:
$ns-color__blue—dark: rgb(25,25,112);
$ns-brand__color—primary: $ns-color__blue—dark;
// component.scss
$ns-component__color—text: $ns-brand__color—primary;
Material Design uses values that are similar to font-weight
! That means you’d end up with something like a base range plus alternates:
$light-green-100:
$light-green-200:
$light-green-300:
// etc
$light-green-900:
$light-green-A200:
$light-green-A400:
$deep-purple-100:
$deep-purple-200:
$deep-purple-300:
// etc
$deep-purple-A900:

How might you pick names for colors? You might get a kick out of what to call a sunny yellow versus a sunflower yellow, or you might just want some help. Here’s one project for that, and here’s another:
See the Pen Color Namer by Maneesh (@maneeshc) on CodePen.
There is even a Sublime Text plugin for converting them (to whatever syntax you want):

And since we’re on the topic of naming:
I personally use Chir.ag’s Name that Color utility. I’ve been using it for years and I LOVE it. http://chir.ag/projects/name-that-color/. I first give a name to all the colors I use using that tool, for example “$color-cornflower-blue: #6195ED;” and then I create variables like $nav-bg-color: $color-cornflower-blue. That way if I ever need need to update a color, I update it in a single location, on a single variables file.
Ha! I just named a color variable
$cornflower
yesterday. :)I’ve generally stuck to themes (typically fruit) butI really like the idea appending the actual color on there — hadn’t considered that.
I do this too, but with the help of an app. Sipapp.io uses a lot of those color names by default, so I’ve created some custom formatters so I can just cmd+click the colour dock and have it added to my code. Gave up on naming colors after reading David Walsh’s post: https://davidwalsh.name/sass-color-variables-dont-suck
Pretty much this. Best flexibility you can get.
Opps, just saw your comment after adding my own. I also use this website (have done so for the past 4-ish years).
I also use this technique. It’s easier to navigate, for me, and when i need to change a color slightly, i change the values. When i need to radically change the color, i switch the variable in the attributes.
I’m using variables in this way. I try never to use colournames or positions. So everything can change easily.
To avoid ‘look-a-like colors’ I use http://www.color-blindness.com/color-name-hue/ with great joy for many years. Implementing these color-name-variables I use the same tactic as Emma does.
I use both color names as variables, and UI color configuration variables. Here’s what I mean:
I like this because I pull partials from project to project while changing the brand colors. This way I only need to configure colors in one place rather than following my compiler errors all over the place. I also prefix variables so I can use my autocomplete tooling in Visual Code to look them up quickly.
I like to think of my variables file almost as a “class” with
public
andprivate
properties for colors and sizes.For colors, I’ll typically really only use brand/theme-related colors, a palette of grays, and status colors (like success, warning, danger, info). In this case my “private” colors that I only use within my variables file would be a one-to-one for a named color and a hex code, like
or possibly further variants like:
Then I use those named colors to define my “public” variables, like:
This way I could re-theme my whole app if need be (or to a lesser degree, re-color an element type) and not have to worry about either a color name not matching its hex, or having to change all my instances of
$shamrock
to$spruce
throughout many files.I humbly think that CSS Color module level 4 may solve this common problem with the color-mod function, and remove the need for color variables, at least for variations like dark, light, accent, secondary, etc… Some mixins might still be required to make things (shadows, highlights) properly, ie. lowering saturation when rising brightness, and vice-versa.
It definitely depends on the project I’m working on. If there are set guidelines, I have to follow them, but if I’m playing around for myself, I’m using names that are descriptive for me and will remember 6 months from now. You can watch my latest video where I use them to give color on the website I’m creating https://youtu.be/qS2iNHQ1kZA
::)
Having worked on the AngularJS Material team, I’m partial to Primary, Accent, and Warn. But I also use the material colors like “green-500”. But I don’t use the same values. I use the rgb values to use custom opacity. And then I use CSS variables as a theming mechanic:
https://github.com/clshortfuse/materialdesignweb
I use this website to name all my SCSS colour variables — http://chir.ag/projects/name-that-color/
I never have much trouble coming up with variable names for colors in my css, I use the same principle in every project.
For brand colors I use the folowing:
$color-brand-1st
,$color-brand-2nd
, etc… When there are lighter and darker variants of color I just put-light
or-dark
. Behind them. I try to have a maximum of 5 color variants per color.My color definitions would look something like this:
I generaly strike to be as abstract as i can because lets say we ha a variable called $red: red. Now if the brand identity changed to blue we would have $red: blue. Which is confusing.
I have tried many different approaches to naming conventions and found that the following works fine.
Define meaningful color names – they should either come from an online color pallette eg. – http://chir.ag/projects/name-that-color/#6195ED or from brand guidelines eg. $toyota-red: #fc0000;
Map meaningful names to actual implementations:
It’s a simple approach, but proxying implementation colors to our defined colors means we can change the implementation without breaking or renaming the actual colors, just be sure to not use the meaningful colors directly.
Neil
I personnally prefer having 2 level of abstraction for colors:
1. I name all my colors ( $eerie_black: #0d1321, $mesty_rose: #ffeddf, $flame: #d85922, etc.)
2. I add the second layer: with semantic names: $color-primary-default: $flame, $color-text-default: $eerie_black, etc.)
The first layer goal is to give a more human freindly name to colors and lets you use them as basis.
The second is the one I’ll use over all my css. To help remembering the names I always use go from the more global to the more specific (level 1 : color/size/etc., level 2: primary/accent/warning/etc., level3: default/lighter/etc.) with this method I can have the autocomplete helping me to remember the names and suggest the good variable.
This also helps me with theme swipping or color changes over the app/site
I very often try to keep names semantic. For example, when I define “accent”, I don’t want to know whether it is yellow, green or blue. I just want to know that this is the color used for accents. Same goes for “leading text” etc. Sometimes I do break this rule and name those variables with color names. But this tends to bite me right after I do this, especially when the project is just starting.
We are using the sketch plugIn prism to generate color names. https://github.com/ment-mx/Prism
The plugIn generates the names of the colors.
Another benefit is the same color naming in sketch and css.
I’ve been doing it like this for years (firstly with LESS, and now with SASS):
Then consume base colors at component level – e.g. buttons:
I like this one!
I always go with simple $red, $blue, $dark-green, etc. and I keep all of my global variables (usually that also includes @media breakpoints and often general spacing units) in the same place, either at the top of the file if there’s just a single stylesheet or in a variables-specific file. I see the benefits of other naming conventions, but with my general organizational system this works well. If I have brand colors to work with, instead of just setting $primary-color or –primaryColor to a hex value, I’ll define the colors as before and then assign those SCSS variables to the CSS variable properties. That way I can set –primaryColor for an entire section or page or site but still have clearly named values associated with it, and it makes it easy to change the –primaryColor in an intuitive way.
I started to use on this way, but sometimes just get too long =(
:root{
--c-primary:#66287f;
--c-primary-dark:#270036;
--c-secundary:#00c5cd;
--c-text-primary:#ffffff;
--c-text-secundary:#656565;
--c-text-secundary-light:#cccccc;
--c-aux:#d68b00;
}
Call me old fashioned, but I like to call my colours after the names of my colours. Blue being blue, red being red, and grey being light-grey… or medium-grey.
It’s my current project, WIP stuff. So, there were some mistakes
$grey-l20 should be hsl(0, 2%, 20%), of cause
and $color-secondary: $grey-l16.
What I’m exploring right now is a mix of multiple naming schemes. Sometimes you want a specific color (e.g. the warm color for a warning), sometimes you just want whatever the accent color is. To be semantic, you should be able to reference either. So, I define variables like –color-green, –color-red etc, and then alias them, like –color-accent: var(–color-red); etc.
Time will show how this will do, but so far it seems better than picking an individual naming scheme.
My struggle with colors:
I don’t actually reference any colour directly in my actual css. I create maps that parallel my ITCSS architecture, where successive maps reference only preceding ones as much as possible, in a theme file at the start, and then use a helper function to return whatever token (doesn’t have to be a colour; I have a sister config file with spacing, font-size, etc.), passing it the map and a list of strings that is the path through the map to the value. Huge benefit of this is to allow use of defaults and graceful failure for undefined values and a self-documenting cascade.
Re: defaults: if a value isn’t defined, but the rest of the path is valid, it’ll look for a ‘default’ key, even halfway through the path. So I would reference a component colour through that component’s map, but it would reference the fill map, or the type map, etc., which would ultimately reference a generic colours map, where each value is named according to whatever colour it literally is.
so
token($btn, fill)
would resolve to#00f
given the following maps:And all it takes to set up a theme is to declare a duplicate structure (or however much of it is needed) in some preceding custom theme file, wherever that may be, and in the base theme file do this instead:
I use
name-that-color
by Chirag Mehta and it’s absolutely golden. I struggled with naming color variables for years – since I discovered named+abstract colors I never looked back.I typically use the song titles of the album I am listening to a lot, i find this keeps me more engaged
I feel like I went through the same journey of color variable naming as you described in the beginning of your article. One thing that has helped me recently is Visual Studio Code’s Intellisense of A) telling me the value of a sass variable when I hover over it and B) suggesting variable names as I start to type them. Sorry not sure if it was out of the box functionality or if it was a Sass plugin I installed. Thanks for the great article!
Hi!
Thanks for sharing!
Several years ago I designed enterprise color framework to be used for all our applications. The idea was quite simple, color names should not refer to a specific color or UI element. So I broke down colors into several meaningful types:
– Fills
– Strokes
– Lines
– Text
– Alt colors
Then I broke down each type into categories:
– Basic: Most of the UI elements are using these colors
– Contrast: Dark colors for all high contrast elements
– Accent: Colors for CTA elements
– Text: Colors to support typography
– Generic: Generic colors
And finally I’ve introduced gradients for each category
– Strong
– Medium
– Base
– Light
– Subtle
So I ended up with some sort of hierarchical namespace for the whole palette.
We do support light and dark color themes and the color framework worked out quite well. Each palette is defined in XML file and converted into corresponding *.scss file during project build.
This approach prove itself to be very flexible and time saving on large projects. By the way, Microsoft introduced something very similar for their UWP apps – https://docs.microsoft.com/en-us/windows/uwp/design/controls-and-patterns/xaml-theme-resources#the-xaml-color-ramp-and-theme-dependent-brushes
Seeing how naming things is hard, I’ve created a npm library for this:
https://github.com/reneroth/colornamify
And a VS Code extension:
https://marketplace.visualstudio.com/items?itemName=reneroth.colornamify-code
Maybe this is helpful to someone else :)