UPDATE 09/02/11: This project is now available on github: https://github.com/moagrius/Color. Generally, the most recent updates will be found there – I’ll try to keep this page updated as well, but consider the repo linked to be ‘official’. Also proposing this as the new AMD module for the next major MooTools release (https://github.com/moagrius/Color-1).

If you’ve seen or worked with most of the other Color classes out in the wild, please read on – the following class is a little different.

While there are several pretty well established Color classes available, most aiming to be OOP, I’ve found that most are pretty similar and not as flexible as I’d like – they generally take a value of one type and do a straight conversion to another type (e.g., RGB to HSL).

A color is a color – it’s not an RGB color, or an HSL color, or an integer or hex value – it’s blue-green, or lavender, or semi-transparent pink. We should be able to access any component of that color, and retrieve or modify it, regardless of how it was created. If #FF9900 is the hex expression of orange, we should be able to easily increase the brightness of that color, or reduce it’s opacity, without having to quantify it as a different “kind” of color – and that same orange Color instance should be able to express itself in any format, easily.

I wanted a Color instance that was agnostic – that could be composed in any format, updated using any component, and output whatever you want. E.g., create a Color instance from a hex value (or CSS named color), increase it’s brightness (an HSV component), and then output it as HSLA, hex, and retrieve the modified red component – each act requiring a single statement:

I won’t get too deep into trying to document it in a blog post, but it can accept pretty much any kind of color value (including the returns of pretty much any browser’s current/computed CSS color value) as the single argument in the constructor (or updatable with the .parse method), and output whatever you want. There are some sugary methods for valid CSS color values, but the .format method will spit out pretty much anything (I’m still debating on whether to allow expression evaluation – for now, it does not). No matter how it’s created (or updated), any component can be set using a method of the same name (color.red, color.lightness, color.brightness, etc.). These method invocations also return the actual value, even if no argument is passed (jQuery style). Note that both lightness (an HSL component) and brightness (an HSV component) are supported, and can play with each other.

Standard caveats apply: it’s not documented (or even commented), and it’s not thoroughly tested. Any math taken or inspired from elsewhere is credited – if I missed one, please LMK.

The class is completely framework- and tookit-independant- while it’s “dom-ready” (in that it tries to parse incoming CSS values, manages named CSS colors, and has some helpers to output valid CSS values), there’s no direct interaction with the DOM. It can be used standalone or with your favorite library (jQuery, MooTools, etc.).

Here’s a very quick POC fiddle: http://jsfiddle.net/Z67XE/
(note that the fiddle has MooTools as the selected framework, but doesn’t use any MooTools methods).

And the class: