Color Variable Names

Love that idea (and that website).

I like your suggestion for a descriptive naming convention for colours but, more important, in my opinion, in the context of Omega 4 Ohm, is to remove all explicit $colour-name variables currently to be found components' _partial.scss files and replace them with descriptive names like e.g. $sidebar-text-colour, $normal-link-color, $hover-lik-color or whatever. This means that changing the sub themes colour palette is then as simple as editing a single _partial file e.g. _color.scss rather than having to do global edits on multiple _partial.scss files distributed around the theme directory.

Then, in _color.scss we would see a mapping of more "functional" variable names to your suggested more descriptive colour names.

I have done this in my Omega sub theme after having stolen many _partial files from Ohm and would be prepared to turn into a patch for Omega / Ohm if others thought this worthwhile.

... but, more important, in my opinion, in the context of Omega 4 Ohm, is to remove all explicit $colour-name variables currently to be found components' _partial.scss files and replace them with descriptive names like e.g. $sidebar-text-colour, $normal-link-color, $hover-lik-color or whatever. This means that changing the sub themes colour palette is then as simple as editing a single _partial file e.g. _color.scss rather than having to do global edits on multiple _partial.scss files distributed around the theme directory.

I am very much against that. I have been advocating against over-using variables for a long time now. The whole point of Sass is to ease the styling process. Cluttering your partials with dozens of overly specific variables makes it less than pleasant to maintain a project. Changing the color palette of an existing project is a rather unusual task and, if required, can still be done by simply search&replace-ing every occurrence of the color variables. Variables should be easy to find, re-use, etc. and not be used to over-complicate your stylesheets. There are many articles on the web cursing Sass variables for that reason: People mis-using them. Same is true for mixins, extends, nesting in general, needless loops, etc. Overdoing things quickly removes the whole benefit of a system. Don't do it.

Only use variables when it actually makes sense. And give them names that don't give you headaches when writing your Sass. Make them nicely readable, descriptive and easily to find with your IDE autocompletion.

I've seen projects with more than a hundred variables before. Trust me, it's not pleasant, nay... *impossible* to maintain such a project. Especially if you are working in a team.

Well, I prefer using variables with more functional descriptive names and keeping a map to specific colours separate. This makes more sense to me and is an appropriate use of variables and has made working with my ohm-derived rules much more *possible*, so there we go. It has relieved the headache of working with a client in real time showing them different colour palettes. It simplified my task rather than complicate it as you suggest it might have done.

I don't see variables like "$sidebar-text-colour" being used more than 1-2 times across the entire stylesheet. What's the point of a variable that you only ever use 1 or 2 times?

For me it makes sense to define the color palette for the project as a set of variables of even using Sass maps ... but then just reference those in the actual implementation instead of crafting a overly complex tree structure of variables that you have a hard time to debug later on. I don't want to debug a stylesheet where I have to follow trail of 3,4,5 variable definitions referencing each other. I think that's what people call "leaky abstraction".

I don't see variables like "$sidebar-text-colour" being used more than 1-2 times across the entire stylesheet. What's the point of a variable that you only ever use 1 or 2 times?

. That's not the point. The point is to have a limited palette of colours (as Ohm does) and group together all the things that use that colour e.g all orange things. So in a five-colour palette you have 5 groups of variables in _color.scss. In your editor: Select the group's colour code / name (no I don't use a variable for the code, but I could); change it; save; show client the effect of changing one of the 5 colours. That's how I used it. It did the job for me.

Your second point assumes an extreme case I would not want to adopt.

This shows what I found a useful improvement to Ohm as it stands:

.
.
.
/* mid-blue */ 
$h2-colour: #077dc3; // mid-blue
$h6-colour: #077dc3; // mid-blue
$fieldset-title-colour:  #077dc3; // mid-blue
$th-colour: #077dc3; // mid blue
$action-links-colour: #077dc3; // mid-blue
$messages--status-colour: #077dc3; // mid-blue
$progress-filled-colour: #077dc3; // mid-blue 

/* dark-blue */
$block--nav-bar-a-hover-colour: #064771; // dark blue
$block--nav-bar-a-focus-colour: #064771; // dark blue
$blockquote-colour: #064771; // dark blue
$fieldset-title-hover-colour: #064771; // dark blue
$site-branding__name-hover-colour: #064771; // dark blue
.
.

This separates management of the colour palette from the typography and page layout. This has proved a useful abstraction and worth the trouble of editing Ohm's component _partial files.

So, once the groups of variables (the "palette") are varied and demonstrated and the client is happy with the colour palette, then the site-building team isn't landed with anything less manageable to maintain. BTW Variables seldom needed to move from on colour group to another in the palette.

Getting back to the topic of this thread, adding an extra level of indirection with more descriptive colour names instead of the hex colour codes may, or might not, help a lot but I doubt would cause team apoplexy.

+1 for functional names over the names of the colors themselves. If you're just defining a variable to be a specific color (i.e. $blue-light), and you then later decide to change the palette (let's say... you make it red instead of blue), you have two ugly choices:

• Search and replace the whole project where you use "$blue" and change it to "$red"; OR
• Keep the variables named $blue-X even though they're now reds, making it confusing for anyone coming on the project down the road.

Functional names just make sense, especially if you're creating a reusable theme or one using the color module.

I have been advocating against over-using variables for a long time now. [...] Variables should be easy to find, re-use, etc. and not be used to over-complicate your stylesheets. There are many articles on the web cursing Sass variables for that reason: People mis-using them. [...] Overdoing things quickly removes the whole benefit of a system. Don't do it.

Well, I guess I'm probably guilty of over-using color variables. One reason this might happen is that people who are first learning SASS find color variables one of the easiest things to start with, and it is terribly easy to start off overusing it in your very first SASS project - which in my case was an Omega sub-theme based loosely on Ohm.

Here's a sample of how I used color variables that touch on several of the strategies above. It uses descriptive color names for actual colors, and it also uses the generic-to-specific color names for the variables used for specific functions or structural purposes on the site.

First, I defined variable names for specific colors, so that I could refer to descriptive color names. For, e.g.:

$black         : #000000;
$white         : #ffffff;
$purple        : #561b58;
$dark-green    : #315a0f; 
$light-green   : #67a045; 
$light-grey     : #eeeeee;
$light-mid-grey : #d2d2d2;
$mid-grey       : #888888;
$dark-grey      : #333333;

Then, I defined "abstractions" and assigned the variable colors to those abstractions:

$color-primary             : $purple;
$color-secondary           : $dark-green;
$color-tertiary            : $light-green;

$color-background          : $white; 
$color-background-inverted : $dark-green;
$color-border              : $light-grey;
$color-line                : $purple;

$color-text                : $dark-grey;
$color-text-inverted       : $light-grey;
$color-text-darker         : $black;

$color-shadow              : $dark-grey;
$color-shadow-lighter      : $mid-grey;
$color-shadow-darker       : $black;

$color-heading             : $dark-grey;
$color-heading-darker      : $black;

$color-link                : $purple;
$color-link-inverted       : $white;
$color-link-disabled       : $mid-grey;
$color-hover               : $dark-grey;
$color-hover-darker        : $black;
$color-hover-brighter      : $dark-green;
$color-hover-disabled      : $mid-grey;

All these were defined in the _colors.scss file. In the rest of the SASS files, I used colors according to functions or structure as defined in the abstractions.

This does seem a little over-complicated to me now when I look at it!...but perhaps it provides food for thought for other themers?

This general technique has been suggested by a number of bloggers in the past, though I forget exactly where I read about it first. The Jim Nielsen article referenced in the first post more or less implies this approach, but not entirely. Here is another source that advocated this approach in 2013:
http://sachagreif.com/sass-color-variables/ [Sacha Greif]

And here is one of those arguments that decries the over-use of variables:
http://bensmithett.com/stop-using-so-many-sass-variables/ [Ben Smithett]