Demystifying colour management

Colour management is a pretty arcane subject to most people, even if it’s relevant to their work. I recently spent some time trying to understand it, and encountered two challenges. First, I didn’t find any really clear explanation of the concepts involved. Some are thorough but difficult to follow. Others give practical advice without elucidating the fundamentals. The second problem is that there’s conflicting advice about best practices when designing for the web.

I’d like to take on the challenge of addressing both of these issues. I will first explain some of the basic concepts behind colour management, using illustrations that hopefully make it easier to understand. I will then talk about practical implications for web-oriented design.

How it works

Colours can be described in different ways, for example as a mix of red, green and blue light, or in terms of their hue, saturation and lightness. In each of these colour models, you can think of the dimensions as forming a "space". One such colour space is called CIE xyY, and I’ll use it for my illustrations here. It contains all the colours visible to the average human eye, and has the convenient property that, although it’s three-dimensional, you can look at it "from above" and get a nice, two-dimensional map of chromaticities at maximum brightness:

When you’re working on a particular display, it’ll only be able to show a subset of all visible colours. This range is called its gamut and will have a triangular footprint in the CIE xyY space (as will any other RGB space):

If a colour profile describes a sub-space like this which exactly corresponds to the range of colours your display can actually show, it’s said to be perfectly calibrated.

Clickable control labels for the web

One of my pet peeves in web interfaces has always been that on radio buttons and checkboxes, only the small button itself is clickable. In native Mac and Windows interfaces, you can usually click on the text labels of these controls as well, giving you a much larger target, which, in accordance with Fitts' Law, makes them faster to hit.

Many, or perhaps most, people would probably never notice this difference in behaviour because they have only ever tried clicking on the button proper; the text doesn't visually suggest that it's clickable. But for those of us who are used to this shortcut, the standard web behaviour will catch us out every time. (Actually, I've started to wonder whether I'm the only person on the planet to click on the text labels, since I've never heard anyone else complain about this issue.)

Until a few months ago, I thought this was all just an unfortunate but inevitable limitation of HTML, and that developers found it too much hassle to implement a workaround in JavaScript. Then, I discovered HTML's label element. If you mark up a piece of text as a label and set its for attribute to be the ID of a form control, it becomes the "official" label for that control. The practical effect of this is that in most browsers, clicking the label will actually do something useful. For checkboxes and radio buttons, it will toggle their state, while for text fields, it will put the focus on the field. This works in Internet Explorer 6(!) and 7, Safari (I only checked version 3.0.2), Firefox and Camino. OmniWeb will do it in the upcoming 5.6 release.

So code like the following:

<input
 type="radio"
 name="os"
 id="mac"
 value="mac">
<label
 for="mac">Mac user</label>

<input
 type="radio"
 name="os"
 id="windows"
 value="windows">
<label
 for="windows">Windows user</label>

<input
 type="checkbox"
 name="loving_it"
 id="loving_it">
<label
 for="loving_it">And loving it</label>

results in nice, fully clickable controls like this:

Mac user Windows user And loving it

There's also an alternative, simpler syntax that doesn't require using the for and id attributes. Instead, you can just make the label element a parent of the control:

<label>
  <input
   type="radio"
   name="os"
   value="mac">Mac user
</label>

However, this does not work in Internet Explorer 6, so if you want to be inclusive, stick with the more explicit syntax.

Web site redesign

I've just launched a redesign of my web site, which makes it the fifth version, if I recall correctly.

It's based on a simple grid with six columns of 100 pixels width and 20 pixels in between. Those are pretty much the same dimensions as I used for UIScape.com, and I've found them to work quite well: narrow enough to allow some flexibility and wide enough for most content. However, it only works if you have a very narrow sidebar. (With UIScape, I had to cheat by adding another 20 pixels on the right.)

I used to have a strange aversion to using non-white backgrounds, but this time I had a very particular look in mind, so I decided to just go for it. I was going to at least use PNGs with transparency for all the graphics, but too many people still use bloody Internet Explorer 6, so the background colour is fixed in the images.

This new site includes Google Analytics code for tracking statistics. I think this may be causing a delay when loading pages. I hope this is not too noticeable or at least not too bothersome for people. (Basically, I load and run the Google Analytics JavaScript at the start of the page, because I make in-page calls to it for tracking downloads and outbound links. If you know of a way around this, please let me know.)

CSS3 multi-column layout

http://www.w3.org/TR/2001/WD-css3-multicol-20010118/

As you can maybe imagine, I'm quite excited about this. I wonder when WebCore- and Gecko-based browsers will start supporting this. Although I guess adoption by web designers will be scarce until Microsoft gets its act together.