There are a lot of programs and systems and so on that let you specify what I'll call 'absolute colours'; this RGB value for the foreground, this RGB value for the background, and so on and so forth. My personal opinion is that this approach to specifying colours is too low-level for most uses.

We know a fairly large amount about how people perceive colours in relation to each other; some of it comes from scientific research and a great deal of it comes from the surprisingly pragmatic world of art. In practice, you almost always want to specify colours that follow the principles derived from this knowledge. Or to put it directly, you almost always want colours that work well together in whatever relation they're supposed to have.

This is why I say RGB-based colour specification is too low level. In practice you do not pick RGB values out of a hat with no reference to each other (at least not if you want the result to look decent); you go through some process of harmonizing the colours and deriving some colours from others, working out all of the RGB values in the process. What I really want for specifying colours is something that automates this; it would let me start with a base colour or perhaps a small set of colours and then derive other colours from them through perceptual operations like 'make a desaturated, less obvious but still readable version of the foreground colour'.

(I know, desaturation is a basic and sort of simple operation. I'd like much more ambitious features, such as automatically deriving complementary colours and avoiding colour pairings that cause problems for people with various sorts of colour blindness.)

This grump is brought to you today by xterm, where the common set of colours are specified as absolute values and are definitely not designed for black text on white backgrounds, red text on white backgrounds, or in fact any of the foreground and background colour combinations I use.