Colour variable names that scale

I think we can all agree, naming things is hard. I’ve got two daughters, and naming them was tricky. Largely because when you name a thing that is going to outlive you, you don’t really want to name it after someone you don’t like. Turns out that I don’t like many people.

It also turns out that naming children is a walk in the park in comparison to naming colour variables. So I wanted to take some time to go over my current approach and how I’m finding it.

It’s early days, and I don’t hate it yet. Which at this stage, I’m willing to take.

For the examples below I am using SASS and a very basic colour palette.

Start with a palette

First things first. I strongly believe you need a colour palette, and that is your single source of truth.

The palette will – depending on the size of the project – be defined by a design team, by you, or more scarily; by reverse engineering the hard coded colours out of your stylesheets!

The palette will be declared at the top of a _colours.scss stylesheet, and all the other colour variables will point to those. Something that you can be held accountable against.

There are many benefits to this approach, not least the fact that you can see all the colours that are used in your application in one central place. Seeing all the colours in one place like this helps us rationalise and consolidate — especially when using a code editor that shows the colours inline. Maybe there are two shades of red that are very similar, and you can then make a call about whether it makes sense to consolidate them into one colour.

If two colours are really close together, and you feel like you do need both, then consider using a colour function like lighten or darken to get the same effect without compromising the palette.

This approach also means that you know where all your colours are defined. You’ll now never have to worry about an obscure colour being defined deep in a stylesheet you’ve forgotten about. To reinforce this approach, you can lint against it. Talking about automation leads us nicely onto the next section.

Automate the naming

As mentioned above, it’s really hard naming things. So wouldn’t it be great if something else could do it for you? If I’m left to my own devices, I end up with something along the lines of $clr-grey-dark-but-darker-still, and then question if I’ve made the right career choices.

The best method I’ve found to name colour palettes is to use the Name that Color online tool. This tool will generate colour names for you based on a HEX value. Suddenly #254E70 becomes astronaut. Big ups to Chirag Mehta, the developer who created this!

So it’s not long until the above palette looks like this in code.

Before we all go home to celebrate and begin applying our fantastic new astronaut colour everywhere, there are a some things we should consider first…

Call out common colours

Every application will have common colours for functionality. Font colours, border colours, and the like. We may even want to call out a couple of the colours as primary and secondary. Anything to help us out, and stop us repeating ourselves.

I generally prefix these with something unique so that I can easily spot them.

These are our common functional colours. They describe what they are going to be used for. The benefit these variables bring is that we can change things like the border colour in one place rather than in hundreds of places, and you start to familiarise yourself with the variables when looking through your styles.

Component colours

I’m currently working on a large component library, and it just feels cleaner to never reference a palette or functional colour directly in the component classes.

A couple of reasons for this, it means that I can have more explicit control over my colour usage. We won’t be able to cover all colours in the functional section, so then you start to second guess at what level the colour declaration lives.

Also if my component is a complex one, I may well have colours in there that are repeated for similar classes. So that should be a variable, right?

So it feels cleaner to define all the component colours variables in a block, and then reference those colours within the component itself. This might sound like a lot of overhead, but I can assure you, it will pay off in the long run.

After all that, you will end up with something that looks like the following:

Conclusion

I think it’s safe to say that there are no silver bullets when it comes to this stuff. There are caveats to the above approach, but with anything there’s a cost benefit analysis to consider, and for me the benefits are so far outweighing the negatives.

If there’s anything to take away from this, it’s that it pays to have rules and to follow them. Know where your colours are defined, live off a palette, and prefix where it helps.

And for goodness sake, don’t name your kids after someone you don’t like.