I’ve been interested in the new possibilities Sass allows for managing and manipulating color palettes for a while now, so I like to see what others are discovering. In “Aesthetic Sass 2: Colors and Palettes”, David Khourshid shares some interesting tricks for staying organized and some tips for tinting and shading, which I’ve covered before.

In particular, I’m curious to explore how Sass maps can iterate on and organize colors, and how we can use Sass to aid with color contrast ratios. There’s some good stuff in there.

I’m keen to touch on one point where I’m not sure I agree, however. Early on David writes:

It is highly suggested that palette colors are named semantically rather than on their appearance. A variable like $color-blue has little meaning (other than that the color is blue), whereas $color-primary defines the color’s role semantically.

I agree with him in that this is an ideal strategy for creating a template that can be themed in multiple ways, but in my experience that’s the only time a semantic naming system is necessary. But for other kinds of projects, like client or in-house work, you could name the colors however you please without much trouble.

Besides that, is it immediately semantically clear what the distinction is between a secondary color and an accent color? In the case of the palette I use on Evergreen’s website, Evergreen Neue is clearly the primary brand color, but what is the secondary color? Is it Sky Blue, Wine, or Blueberry Susan? The answer is none of them; I use whatever feels appropriate. Blueberry Susan, as one example, is often used as the go-to color for UI elements, but it’s not reserved solely for that purpose.

In his exmaple, $color-blue does have an important meaning: that the color is blue. In “The Joy Of Painting”, when Bob Ross tells us which colors we’re going to be painting with today, he doesn’t squirt a bunch of Phthalo Blue onto his palette and say, “Get your knife out and scrape up some Primary Color.” In this way, human names make much more sense. Perhaps that’s a bit too Wild West for your typical pragmatic developer, but I believe that my designs looks more balanced for it. I sometimes choose a color based on the need, not based on the color’s role.

As far as the argument about changing brand colors on a whim, sure, a semantic palette would make this easier. But with variable names, it’s not that much easier than a simple global find-and-replace. Especially since the point of a brand palette is consistency and familiarity. Which is to say, they don’t change often by definition.

I think creating this rule for semantically named colors is giving in to the ever-encroaching bounds of pragmatism into design. We just rescued color names from indecipherable hex codes and hsl values and now we’re frothing to push intuition back out of the design sphere.

I want to make it clear that I don’t have a problem with semantic color palettes, full-stop. In fact, if anything I’ll mix and match my named colors with semantic tint and shade colors (which he ironically doesn’t use variables at all for). I just don’t see a truly compelling reason to make the recommendation “highly suggested”.