Many of our methodologies around designing in code have arisen through the principal of reducing cognitive burden on the designer.

At Omni we design almost exclusively with code and in-browser. We, and our clients, have benefited greatly from this approach; we spend less of our time and less of our clients’ money mocking up static designs, agonising over which dummy images will best sell the design, and then translating these bitmap mockups into templates, components, styles and behaviour. Most importantly, we’re able to address from the very first sprint the challenges that each design will face in a world of varying devices, viewports, and evolving standards.

Designing in code from the outset, without using third party graphic design software, is a relatively young and underdeveloped approach to building software for the web. As such, we’re keen to stimulate discussion around techniques and issues that other designer-engineers are facing in the wild.

In that spirit, I’m going to explore why we’re moving to using the hue, saturation, lightness and alpha (HSLA) colour format for applying colour to our components on the web, and the resultant benefits we expect. This won’t be a technical deep-dive, though HSLA is a relatively simple concept to grasp.

Many of our methodologies around designing in code have arisen through the principal of reducing cognitive burden on the designer. If a designer has a defined set of fluid spacing variables to use, they won’t need to constantly deplete their focus by creating a range of pixel values for each element at varying viewport widths. So far, colour has been left out of our process of simplifying our day-to-day design and development workflow.

Our current colour workflow, for clients who don’t already have well-defined branding, is the only part of our design process where we’ll reach for design software. We’ll usually select a colour, then define variations on that colour, editing the hue, lightness and saturation by defined amounts until we have a range we’re happy with. From here we’ll select complimentary colours, keeping in mind their semantics, and repeat the steps we took earlier to define variations of these colours. The hex values of these colours are then copied and pasted into our Stylus code. This can be dull work in a program like Illustrator, and when colours need to change, as they often do, each step of this work needs to be repeated. As we’re already programatically selecting variations on our colours, albeit in a quite rudimentary and manual way, this repetitive, multi-step process is a fine candidate for moving into code, thus saving our time and effort.

What is HSLA, and why would we use it?

The most widely used colour format on the web at present is the hex triplet; a six-digit, three-byte hexadecimal number. The bytes represent the red, green and blue components of a colour, using the RGB additive color model. There’s also a widely-used CSS colour function called RGB, in which you can directly input the value of the red, green and blue light sources in each pixel, between 0 and 255. Neither of these methods of defining colour make any concessions to human readability; they’re a direct map to the way the computer needs to receive colour information.

HSLA is another CSS colour function, based on the Munsell colour system. This function takes the arguments hue, saturation, lightness and alpha. It’s a far more human-readable way to declare colour values, meaning that you can experiment with picking colours as you design in-browser, as well as making it easier to edit colour values in front of a client or product owner for their sign-off.

Hue is most easily understood as colour, though it could more precisely be described as the light’s dominant wavelength. Hue rotates in a full 360 degree circle, and here are two easy ways to remember which colours map to which degrees:

ROY G BIV, an acronym of red, orange, yellow, green, blue, indigo, violet, is quite a simple way to remember roughly where the colours map from 0° to 300°, going from violet to red again between 300° and 360°.

Young Guys Can Be Messy Rascals is an an acronym of yellow, green, cyan, blue, magenta and red, and is a little more precise as it maps neatly to 60° increments, as follows:

  • Yellow: 60°
  • Green: 120°
  • Cyan: 180°
  • Blue: 240°
  • Magenta: 300°
  • Red: 360°/0°

Note that you do not have to use the deg keyword, as you do when declaring transform values.

Saturation takes a percentage value. It controls the blend between absolute greyscale at 0% and full colour at 100%.

Lightness also takes a percentage value. It controls the relative degree of black (at 0%) or white (at 100%) mixed with the specified hue, with black creating a shade and white creating a tint.

Alpha takes a floating point number between 0 and 1. It controls the opacity of the colour, in exactly the same way as the opacity property does. Alpha is optional if we use the HSL colour function instead, but I suggest always including it for ease of refactoring, as well as to better allow us to create useful mixins, as we’ll see later on.

Using HSLA

Browser support for HSLA is excellent, with only IE8 and below lacking support. If you’re still supporting these older browsers, you have our condolences!

There are many tools to convert colour values from one format to another, and the one I prefer is https://www.colorhexa.com.

If you’re writing CSS in a preprocessor, it may seem easier to continue using hex values for your main colours, then programmatically create variations on that colour using your preprocessor’s built-in colour functions, like Stylus’ spin(), saturate(), desaturate(), lighten(), darken(), and alpha(). Having run some tests though, these functions don’t always behave as you might expect; darken($color, 10%), for instance, is not equivalent to reducing an HSLA value’s lightness by 10%, instead calculating the colour’s current lightness value and darkening it by 10% of that value. This means that you’ll get unintuitive results if you set up a range of colours which each reduce the base colour’s lightness by 10% more than the colour before it, for example.

Here’s a Stylus function we’ve written, which will allow you to set a base colour, define a number of variations on the base colour, and define how much the HSLA values will increase/decrease with each variation:

Controlling HSLA with JavaScript

This is largely out of the scope of this article, but I’ll include a couple of examples to get you thinking about what’s possible. Using JavaScript in this way is in line with the ideals of progressive enhancement, and can provide some memorable experiences for users.

Here’s Sarah Drasner using Greensock to animate the HSLA values of SVGs, and here’s Chris Coyier using controlled randomisation to animate the SHLA values of coloured dots.