There are lots of ways of specifying a color on the Open Web:

• rgb(255,0,0)
• rgb(100%,0,0)
• #FF0000
• #F00
• “red”

And it’s not just the 17 CSS color names, there are 147 cool-sounding extended color names like papayawhip. So given that a user can input a color in all sorts of ways, what’s the right way to do this?

The Hard Way

You can build a parser that determines the color format, parses hex and rgb strings and has a table that maps 147 strings to rgb triplets. It turns out there are a lot of JavaScript libraries that already do this. Here’s one.

But then I thought: why am I including yet another JavaScript library to do this parsing when the browser must already know how to map from hex, rgb or color name to an RGB triplet (or equivalent) in order to render the color in the first place? Surely there’s a way to extract this directly out of the DOM?

The DOM Way

It turns out there is. It’s called the CSS DOM and I always seem to forget about this document. Piecing together information from the SVG DOM and the CSS DOM, this is how you would get the red value of a fill attribute on a circle:

var red = someCircle.getPresentationAttribute("fill").rgbColor.red.getFloatValue(1);

That’s just a bit perverse, but at least it’s possible.

In testing this I was delighted to discover that Opera and WebKit let me do it. Sadly, Firefox does not.

The Best-Laid Plans…

Here’s where the plot thickens. Seems like the CSS Working Group was chartered to produce a new version of the CSS DOM to make the interfaces less clunky. Seems like the CSS WG sent out a notice strongly warning browsers not to implement certain DOM interfaces in the CSS DOM. Seems like it’s six years later and there’s no new document.

Unfortunately this is where my sad little tale ends. Erik of Opera suggests that the SVGT 1.2 uDOM is really the right way to do this. It doesn’t matter that I agree with him because I don’t think Webkit or Mozilla have any interest in implementing this any time soon.

It seems kind of sad that folks have to write JavaScript libraries to do color parsing when the browsers already do this natively. It also seems really weird that the SVG DOM interfaces extend obsolete CSS DOM interfaces (SVGColor extends CSSValue which Bert Bos mentions in his email).

#DOMFAIL ?

• 2008-04-29 – CSS Reflections
• 2008-04-24 – CSS Masks
• 2008-04-17 – CSS Canvas Drawing
• 2008-04-14 – CSS Gradients
• 2008-04-08? – CSS Transitions
• 2007-10-31 – CSS Animation (spec proposal)
• 2007-10-26 – CSS Transforms (spec proposal)
• 2006-12-21 – Text Fill and Stroke
• 2004? – HTML Canvas – thankfully this was quickly reviewed and thrown into HTML5 so that Opera and Mozilla could get into the act
• Others -webkit-border-horizontal-spacing, -webkit-border-vertical-spacing, -webkit-margin-bottom-collapse, -webkit-margin-collapse, -webkit-margin-start, -webkit-margin-top-collapse, -webkit-padding-start, background-position-x, background-position-y, -webkit-tap-highlight-color (iPhone only), -webkit-text-security, -webkit-text-size-adjust (iPhone only), -webkit-line-break, -webkit-nbsp-mode, -webkit-rtl-ordering, -webkit-user-drag, -webkit-user-modify, -webkit-user-select, -webkit-dashboard-region (Dashboard only)

Is this a problem?

What’s troubling me is not that many of these inventions could have been done using SVG (which WebKit now supports quite nicely). I understand that XML is not for everyone and that a few CSS properties are easier to pick up to do what you want.

No, what troubles me is that a few of these innovations are not yet proposed as formal specifications so that they can be interoperably implemented in other browsers (Firefox, Opera). [Update: Correction - as Mark points out below, several of these have indeed been proposed as formal specifications - Bravo!] The point of the WHATWG effort was both to evolve HTML and to specify it in sufficient detail so that future browser vendors would not have to reverse engineer de facto browser behavior. Will the WHATWG eventually have to churn out CSS5?!?

On the other hand…

… Apple has a perfect right to introduce WebKit-specific CSS properties. WebKit is more than just a single web browser. WebKit is a platform and Apple obviously wants to put as many cool web development tools into the hands of its developers as possible. They’re already doing a good job at meeting existing open web standards – why not innovate on the side? Also, using CSS ensures that things can degrade gracefully, so you can’t quite fault Apple for ‘anti-competitve behavior’ like you could Microsoft and Netscape’s efforts during the First Browser War.

Unfortunately…

Unfortunately these inventions might have the same secondary effect: Forcing the other browser vendors to spend resources on reverse-engineering efforts in order to remain competitive. This could realistically happen before Apple gets a chance to propose these things formally to the W3C. [Update: See Mark's comment below]. It is much more likely to happen if WebKit were to become the dominant force on the open web.

WebKit is not yet the dominant web browser technology, but it’s fast on the rise. From all accounts, it is much easier to pick up and hack on than the Mozilla codebase. Let’s take a look at where it is being used:

• MacOS Dashboard
• Safari on MacOS
• Safari on iPhone
• Google’s Android
• Adobe’s Integrated Runtime (AIR)
• Qt 4.4+
• Nokia S60 Browser

I’m sure readers can help me add to the above list too. I believe there is a plan for WebKit to ultimately take over Konqueror’s KHTML guts one day too, isn’t there? Ironic since WebKit evolved from KHTML in the first place.

So when will it be a problem?

Are we seeing any signs of a trend towards a WebKit-dominated web yet? There are already iPhone-specific websites. How long before Opera Mobile and Mozilla Minimo want to get in on that action and are forced to reverse-engineer? And I’m sorry, but looking at the source is not an acceptable alternative to a well-defined specification.

A tentative conclusion

After typing up this entry and proof-reading it, I tried to discern if I had any coherent conclusion and if I could figure out just what the heck I was saying:

• Apple is not in the wrong for introducing WebKit-specific CSS properties, I think they learned their lesson from the HTML Canvas experience.
• You also cannot fault Apple for its adherence to web standards. They are definitely doing their job here
• It seems like they plan to propose these things as standards eventually, which is also a good thing.
• I guess the only thing I can say is that I hope these proposals happen sooner rather than later, for the other browsers’ sake. [Update: As mentioned below, Apple has already proposed many of these things to the W3C as specifications, thereby alleviating most of my concern]. Apple should take a page from what happened to DOM Events: The fact that Netscape and Microsoft had two different event models resulted in the W3C proposing yet a third incompatible Event Model, which Microsoft still has not implemented eight years later. Those type of things just hurt web developers in the end.