Please stop including color names in your CSS classes.

Photo by Robert Katzki on Unsplash

This is a very silly class name:

Also silly (from Tailwind):

By specifying the color name in the class name itself, you are partially defeating the purpose of having a class at all.

If the brand team decides to change the default button color from blue to green, you have to do a search and replace on both your markup and your CSS. At that point, you might as well have put “background-color: blue;” on everything, because you’ve got to refactor everything with the “button-blue” class anyway.

The same way we don’t name our breakpoint/responsive classes “bp-900px” — instead we use “sm” and “lg” — we shouldn’t include style values like “red” and “blue” in the class name.

How should I name my color classes then, smart guy?

Here’s an excerpt from a SCSS file I recently worked on, where I was setting up some color variables:

You might not like the specifics of how I’ve named these variables. And that’s fine. (I actually wrote a minor critique of my naming convention here and then removed it for brevity).

For the sake of this article, the specifics of the naming convention are less important than the abstraction in the names. In other words: I’ve separated the actual color value from the name of the class — and that’s what’s really important.

This way, when the color inevitably changes through a brand refresh or an A/B test that shows green is always better than blue, I can just change my variables one time, in one place. Which is a big part of why we’re using classes in the first place.

My CSS classes might look something like this:

And here’s some sample markup:

This allows me to avoid the trap of having values like “blue” and “800” in my class names. If there are other types of actions, I’ll use class names like “interface-action-alt” or “interface-action-secondary”.

Using Tailwind themes to get more abstracted class names

I was initially put off by Tailwind’s use of color “values” inside class names. It can resolved through the use of themes, although I do wish the themes layer provided just a little more flexibility in its keys and nesting of values. But the same conventions can apply there; you can define a theme like this in tailwind.config.js:

You can use the theme in your CSS like this:

Relevant class names are auto generated by Tailwind if you want to skip the CSS altogether:

It seems like a lot of work to classify all the different element types, give them meaningful but well-abstracted names, and account for variations on the defaults.

Yep. And it’s totally fine to adjust the approach if your design system simply isn’t consistent enough to practically allow for this convention. It’s a lot of up-front work to decide on how to properly name both the elements and the state they might be in (enabled, disabled, etc).

But if you’re really thinking about the architecture of your markup and CSS, I’m not sure why you’d choose to go the “color names within classes” route.

--

--

Chief Digital & Technology Officer @Eastern Standard. Lifelong full-stack developer. Jiu Jitsu novice. Aging punk dad.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jim Keller

Chief Digital & Technology Officer @Eastern Standard. Lifelong full-stack developer. Jiu Jitsu novice. Aging punk dad.