A Proposal for Colour Specification in CSS1

Steven Pemberton, CWI, Amsterdam

20 June 1997

Introduction

The problem with a long list of colour names are that they are bad user interface, since they rely on memory in both directions

"What was the name of that dark green colour again?"
"What colour is 'teal'?"

requiring constant referring to documentation.

A reasonable system should be obvious, simple, and easy to use and intuitive

The aims of the proposed solution given below are:

A simple system
Works for both on-screen as for printing
Minimises the number of colour names used
Allows a useful number of colours
Intuitive

Proposal

colour: <numerical-rgb> | <ua-dependent-name> | [[very]? [light|dark]]? <colourname>

colourname: white | black | grey | gray |
	    red | green | blue | yellow | magenta | cyan |
	    purple | orange | pink | brown

The rgb form is left for backwards compatibility and for people who need an exact colour.

UA dependent names allow you to use any colour name the system defines (just like fonts).

The other 'generic' forms allow such colours as:

	light green

	very light orange

	very dark grey

and so on.

The choice of colournames are the 'obvious' cases taken from the X11 list.

There is a very simple algorithm that converts any colour to its [very] dark and [very] light version. See http://www.cwi.nl/~steven/css/rgb.html for examples of the algorithm in use.

While forms like "very dark white" and "very light black" are also possible (and give the same result as "grey"), these are anomalous cases that happens to fall out of the definition, and would be more work to disallow than just to accept.

The resulting set of 57 distinct colours gives a broad range of useful colours (and happens to cover all 16 colours mentioned in the current CSS definition) without overwhelming the potential user, and the style of specification fits in well with the general style of CSS (such as the use of words like 'larger').

While it would be possible to include more superlatives (like 'extra dark blue'), this seems to add complexity without really adding to the usefulness of the system.

It would also be possible to allow colour mixing (such as "very light red+very dark green"), but I believe that many of these mixtures are not obvious, and it would create problems with the definition for printing.

Fallback

One obvious addition that we need is what to do when there are less colours available than can be supported.

Firstly, we need fallback.

    colourspec: <colour> [, <colour>]*

e.g.

    BODY {background-color: mistyrose, #FFF0F0, very light red, red, grey, white}

The 16 colours mentioned in CSS are represented by:

[very dark] [red, green, blue, cyan, yellow, magenta]
black, white, [light] grey

so we should be able to guarantee the following sets will work as fallback sets:

rgb
[[very][light|dark]] name
[very dark] basicname, black, white, [light] grey
black, white, grey
black, white

Secondly we need to define what happens if a colour cannot be supported, and there is no fallback. This should be a simple statement such as "the closest available colour is used", which covers such methods as using colour cubes, without pinning the implementor down too much.

Finally, we need to specify when fallback occurs. If I ask for

      BODY {background-color: #F0F0F1, white}

and the system can't display #F0F0F1, but it can do #F0F0F0, I'd expect that rather than falling back to white.

Steven Pemberton