Sommaire
- Color Values - Opacity
- Colorize SVG
- Color Vars
- CSS Vars & Design Sytem
Ok, here is MY take on this. Your mileage may vary (comments are welcome)…
Btw, it’s vanilla CSS…
CSS variables, and a set for portability Theory!
The goal is to alleviate tedious editions of CSS values within a/multiple file(s), throughout multiple projects, enhancing them mutually sharing best practises and corrections).
This can (should) be combined with a Design Sytem (in Figma, Sketch, …) and a CMS (template/Builder) that may have its own css ‘objects’ definitions.
Basics (defined as :root)
A Base set of ‘primary’ color vars (These are usually accepted colors for butons/interactions), my Var names are :
–info, or default, (usually a value of var(--brandColor(n) or a mid-grey from the default color Scheme) (see below).
–accept, (usually green, or blue; or the brand color)
–warning, (usually a cancel/reset, red-orange)
–danger (a cancel button that would erase all inputs of the user, usually red, a violent red 😉 …
Of course, you need to adapt for your brand Colors. For example, Coca-Cola’s main color is Red witch should/would/could be an accept instead of a warning.
Test with your users!
‘Pure’ color vars
:root {
--pureBlack: rgb(0, 0, 0);
--pureWhite: rgb(255, 255, 255;
}hover color effect
a (:hover) a css variable definition which saturates the color to 100% (or adjusts depending on the brandColor Scheme)
- via a SVG filter (Therefore, default states are not 100% saturated).
- Or color definition for each var state (or a brandColor var, see below)
brute values
A base set of brute color vars (aka brute rgb values). I call these “system colors”
- The color scheme you would change first (and maybe the only one, if all is done well).
- colorDark (black) and colorLight (white) variables, declined in gradients.
Default would be @100% [var(–colorDark or –colorLight), the suffix calls the gradient from lightest to darkest (1 to 5 ±).
ex. var(–colorDark5). Easily reversed in a Dark Mode CSS declaration- You may (I do sometimes) adapt color temperature (blue/red…) depending on the graphic charter or keep them neutral, and have brandColors going to the extremes (B&W).
- For this purpose, depending on the color scheme, I usually invert the 1st and 3rd values on a rgb declaration (rr, gg, bb)., depending on warm or cold color scheme. The middle (2nd value, green) might vary as a X value (in rgb space)
- Of course, you can build a color scheme in another color space (hsl, tsl, lab, …) and adapt values of this rgb example.
console.log( 'Code is Poetry' );
BrandColor Variables
In addition to the “System colors” above, I create one or two (or more*) color schemes (which are not the default ‘system’ black & white) that represent the brand colors (might be red, blue, orange, purple, … or a combo of 2 colors).
Again, I define these variables as a gradient palet (from original (default value – no suffix), from lightest (suffix) (1 to 5 ±) to darkest (1 to 5 ±)), I also suffix the –brandColor variable with ‘Darker’ for colors darker than the original brand color…
*Some use cases (I have encountered):
- One of the ‘brand’ colors changes every 2 years (event)
- The charter precludes otherwise. I have a case with background colors (and therefore text) depending on the color of the product [A calculation nightmare].
console.log( 'Code is Poetry' );
Context & Dependencies
- Declination to individual elements with background alpha using scope of –alpha and var(–alpha) as rgb(a) last value (a). A specific call to transparency values on elements, starting from the initial brute rgb token
- Create link/button… states rules that depend on these variables (or, maybe as svg filter color modifications in variable (applied as a rule)).
[Insert code]
Navigation & links color should reflect (inherit from) the brandColor (or The baseColor (L/D))
Tree view of CSS Variables(colors in the example)
[Code excerpt]Hidden advantage of CSS (color) Vars :
You can conceive your system with modularity in mind and map your CSS with other System/Services much more easier than editing the whole file to change css values (wether you use a plug-in, Zeplin, react/node tool or whatever system you’ve build or are building).
It’s a name Scheme (nomenclature), your Design Sytem / DesignOps can output the code with the right variable names & all users (Designers/Devs) can adopt the same naming scheme.
Your DesignOps can / may be able to translate/map a specific Design Sytem nomenclature to a variable name in your production system.
- Imagine you depend on an external Design Sytem and you have no control over the name changes. You still have control of the variable names in post-production and make changes accordingly… (using grep patterns and scripting, for instance).
- A variable can be redefined at the node level (using !important if the variable was defined @ :root or a previous level in the DOM tree as a last resort),
A (:root) defined variable will exist in the DOM even if it is not used in the current page, it will therefore be available as a CSS value (in The browser Inspector, developper mode). You can call variables in the inspector by typing their name. Very praticle for testing live,
A CSS file(s) constructed this way is easy and fast to port to another website/graphic charter since you only need to change a few original values (colors, spacing, typography …) that are echoed throughout the whole CSS file instead of reviewing all the code,
A CSS file(s) constructed this way is easier to maintain and upgrade to new CSS specs (I have been adapting and enhancing my CSS Stack for the last 20 years! And just went through a complete overall during the writing of these series of articles).
