CSS Colours – An Email

Steven Pemberton, CWI, Amsterdam

I saw a tweet come past:

Extended reading of a Steven Pemberton email on X11 colors in CSS at DHTMLConf.

I didn't even have to put my Sherlock Holmes hat on. I had seen the program for the conference, and seen the title "A Postmodern Etymological Deconstruction of X11 Named Colors"¹, and muttered to myself "He should talk to me". This tweet showed that clearly he had, though not directly. I knew immediately which email that must have been: an email from 12 years earlier. It was a last call comment on CSS3, a web standard I had contributed to, but due to time constraints had not seen to completion. Let me quote the email in full:

Congratulations on an excellent specification. Many of the new facilities will be extremely useful.

With one exception.

The X11 colour names are an abomination that should have been stifled at birth, and adding them to CSS is a blemish on the otherwise excellent design of CSS.

To say that the X11 colour set and their names have been 'designed' is an insult to the word "design". It is just a mess.

Let me just describe some of the problems:

Well, I could go on, but I'll stop here. You get the picture. There is no possible reason that the X11 names should be added to CSS.

There are two possible solutions:

  1. Take the standard 6×6×6 internet non-dithering color cube that is implemented everywhere, and agree on names for each of the colors there.

    But:

    "The browser-safe palette was developed by programmers with no design sense, I assure you. That's because a designer would have never picked these colors. Mostly, the palette contains far less light and dark colors than I wish it did, and is heavy on highly saturated colors and low on muted, tinted or toned colors." - Lynda Weinman, http://www.lynda.com/hex.html

  2. Take a consistent naming scheme that properly addresses all dimensions of the color space, and map this naming scheme algorithmically to appropriate colours. For instance:

    <color>::= [<saturation> || <lightness> || <transparency>]? <hue>
<lightness>::= [very|slightly]? [dark|light]
<saturation>::= [very|slightly]? weak
<transparency>::= [very|slightly]? transparent
<hue>::= <prime> | <mix> | <special>
<prime>::= red | yellow | green | cyan | blue | magenta
<mix>::= orange | yellow-green | green-cyan | cyan-blue |
         blue-magenta | magenta-red (add red-yellow if you want)
<special>::= pink | brown | aqua | teal | grey | gray | black |
             white | purple | silver | turquoise | violet |
             <possible others>

    Examples:

    red

    light red

    very light blue

    weak dark green / dark weak green

    slightly dark magenta-red

    transparent cyan

    See http://www.cwi.nl/~steven/css/colour-lang.html for a quick try at a mapping, which still needs tweaking.

So that was my email. Reading between the lines, you can probably tell I'm not a fan of the X11 colour-naming scheme. Unfortunately, despite my withering criticism, I didn't win the argument: X11 colours did get introduced into CSS, and they did not accept the suggestion of a more systematic colour description language either.

But I had a plan C, which in the end did get accepted, so not all was lost. Let me tell you about it.

Plan C

You see, another problem with CSS, and the Web in general, is that other abomination of colour notations, the RGB colour notation. The problem with RGB notation is that it doesn't describe colours, only implementations of them on a screen. I'll try and explain.

Pure colours are just different frequencies of light, just like musical notes are just different frequencies of sound. The colour 'circle' (it isn't actually a circle, but a trick of our eyes makes it look like one) is just increasing frequencies, from around 430 terahertz for red to around 790 terahertz for violet. The trick of our eyes makes us think that they join up at the ends, which they objectively don't. In fact it is more like an octave in music where a note sounds the same as the one an octave higher (and it is interesting to note that 790 is nearly twice 430, since octaves in sound are just doubled frequencies).

But there's another trick: when you play two notes on the piano, you hear both notes (plus, for perfectly valid physical reasons, the sum and difference of the two notes). However, if you see a mixture of two colours, you no longer see the two colours separately, but because of how your eyes interpret colours, you see a single colour. We learn something about this at school. For instance, we learn that yellow plus blue makes green. In fact this is a white lie. Yellow plus blue makes yellow plus blue, but we see it as green. This is because we have three sensors for colours, which we are taught are for red, green, and blue (another white lie, in fact we have sensors for blue and two shades of green, one of which is redder than the other). Because of how these sensors work, we see yellow plus blue as green, but there is no green there at all. It is possible to have green paint, but there is no way for our eyes to distinguish green paint from blue+yellow paint.

Shrimps on the other hand have sensors for 16 different ranges of colours, and presumably they can differentiate a far greater number of colours than we can. From a shrimp perspective, we are terribly colour blind.

As with paint, so it is for screens. Computer screens are incapable of displaying yellow for instance. When we want to display yellow, we instruct the screen to display red and green very closely together, which fools our eyes into thinking it sees yellow. But if we did a frequency analysis of the screen, there would be no yellow, just red and green.

So the Web specification for the concept 'yellow' is #ffff00. I hope you can see why I think this is a terrible notation. It confronts us with the concept of hexadecimal numbers (if you don't know what these are, you don't need to); it packs three numbers together, and it requires us to know the tricks our eyes play (such as red+green is seen as yellow) in order to represent what we want to be displayed. Worse yet, a printer can display yellow, real yellow, so software for that has to take this RGB value, and convert it into another notation that represents the colour scheme used in printers, not red, green, blue, but yellow, cyan, magenta.

A better notation of colour would express colours in terms of underlying hue, for instance, the frequency of the colour you wanted, so that you really could say "yellow" (or the variety of yellow you wanted, since the word yellow covers a range of frequencies), plus its saturation and lightness. This is better because it describes the colour you actually want, and not an implementation of colour that makes you think you see that colour.

One colour notation that does something along these lines is HSL, which stands for hue-saturation-lightness. It represents the hue in terms of an angle in the colour circle, starting with 0° for red, plus percentages for saturation and lightness. This wouldn't be good enough for shrimps, since they can see colours outside of the colour circle, and a truly universal format could perhaps better use a frequency instead of an angle, so that you could specify a low-saturated infrared with hsl(400THz, 50%, 50%), but nevertheless, HSL is an improvement over RGB since it truly describes a colour, and not an implementation of a colour.

But even though there is that improvement, the main value of HSL is that it is easier to use. User tests have shown repeatedly that people can match a colour far more quickly using HSL than RGB, and in fact most colour pickers in software use some sort of variant of it that allows you to interactively vary the hue, the saturation and the lightness until you have the colour you want. Similarly, products like the Philips Hue lamps, that allow you to change the colours of lighting, allow you to do the same with controls for hue, saturation and brightness.

OK, so HSL is clearly better, and so the CSS working group would be clamouring to adopt it, right? Wrong! Who knows why they had so much trouble with it. Maybe there were people there who wanted to continue selling colour-picker software, and didn't want to make it easier. There really were people who thought that RGB was just fine, and found they were perfectly able to match a colour using it (which may well have been true, but they were very unrepresentative of the audience for CSS).

So time after time, the proposal to add HSL to CSS got turned down. I even got endorsements for HSL from such renowned names as Jim Foley and Ben Shneiderman. I was almost despairing, until one meeting it got accepted, just like that. Who knows why? Maybe the anti-group weren't there; maybe everyone was tired at the end of the meeting and just wanted to go home. I remember the notulist laughed when it got in, after all that hassle.

Yes, I know, CSS would have been much better if I'd stayed in the group. I mean, reordering content using positioning? Sheesh. But really there are only so many hours in a day, and I couldn't see myself spending hours arguing about rounded corners. Nevertheless, if you are grateful for HSL, as I know some people are, you can still thank me next time you see me, by buying me a drink, or offering me a knighthood or something.

--

¹ Alex Sexton's talk: https://www.youtube.com/watch?v=HmStJQzclHc

Acknowledgments: Thanks to Simon St.Laurent (the tweet), Alex Sexton (the talk), and Molly Holzschlag (the liking).

Published 2015-10-19. This version: 2015-10-20.