Yesterday, while stuck in traffic, I was listening to the Styleguide Podcast Episode 1 with Jina Bolton. It got me thinking about color and color variable names in Sass.
Today I am back on a project I worked on more than a year ago and I can see how things have become messy.
Sure many things started out clean and organized, but then you add colors. Then maybe you start hard coding values here and there. At some point, it will certainly make sense to refactor things.
It is one thing to take an existing code base and think about how to refine things and create a nice hierarchy. At that point you know a lot about the project and can make some pretty informed decisions.
But what if you have a new project? How do you approach that?
There are many strategies, but I think it is worth looking at how ZURB Foundation implements color variables.
In ZURB Foundation you have several colors. Let’s take a look at a few.
$primary-color, $secondary-color, $info-color, $alert-color, $warning-color, $success-color
Now, some of these already imply a color. $alert-color a red, $warning-color an warm yellow, and $success-color is a green.
This makes sense in the framework, as you reuse these names on several different components such as buttons, alerts and badges.
But what about $primary color? Well, that is your brand color. If you are Target, this would be red. If you are Google, well, I am not sure what color. The point is, this should be the color you will use the most and that most reflects the brand. Yes, I have worked on sites that used black #000 as a brand color.
But what about $secondary-color? This is a little harder to define. Perhaps you leave it is a gray. Perhaps you have a secondary brand color that you will need to use from time to time. If you have a lot of call to action style elements, perhaps you might use this as a bright orange.
Now many people will just jump in and change these colors in the settings file. For years I have used a different approach.
I have always created a Scss file called brand.scss or brand-globals.csss.
Here I define all of my colors. These often look like $brand-red or $crazy-orange or something like that.
I then create variations of these colors that are used for specific UI elements. Here I like to use a more semantic oriented name. Meaning, it should be named as to what it does. $ui-border-color $ui-shadow-color are two examples.
Then, in a duplicate version of the ZURB Foundation settings.scss file I then use these variable names to start to re-theme ZURB Foundation.
This has worked well for me, because when returning to a project the main brand colors are defined in a specific place.
They are then broken down to more specific variants and named by their actual use.
This makes reading a larger sass file a snap. It makes it it super fast to make changes. It also makes creating a beautiful color section of your styleguide both beautiful, functional and informational for designers and developers alike.
Here is an example from Sass Lang’s public styleguide to provide some visual inspiration.
Color touches every detail of modern web apps. Thinking about and approaching color in a systematic, hierarchal, and logical helps your team to focus on building out quickly and consistently.