I was experimenting with HTML color names the other day. This HTML snippet:

<p><font color='red'>&#x2588; RED</font></p>

got me some red text:

█ RED

(I’m using the Unicode FULL BLOCK 2588 character to get a solid swatch without having to worry about antialiasing effects). Adding a less well-known name got me another color:

<p><font color='red'>&#x2588; RED</font></p>
<p><font color='seagreen'>&#x2588; SEAGREEN</font></p>

█ RED

█ SEAGREEN

What if the name had a space in it?

<p><font color='red'>&#x2588; RED</font></p>
<p><font color='seagreen'>&#x2588; SEAGREEN</font></p>
<p><font color='sea green'>&#x2588; SEA GREEN</font></p>

To my surprise, the “sea green” line was blue! It seems the color name parser in your typical HTML browser is very forgiving, just like the rest of HTML interpretation. Given a nonsense string like “sxbxxsree”, it will decide that some subset of the characters indicate a color, and it will use them.

I played around with more randomized color names, and ended up with a brainteaser on my hands: how exactly does the browser interpret these bogus color names? Note that IE and Firefox don’t agree, though they are close.

I can’t show the effect inline here, because the bogus colors have no effect if the page has real color specifications someplace else, so have a look at the results in a separate page.

Here’s what different browsers show:

At least in the case of Firefox, I could go digging into the source to try to find what it is actually doing, but it is a head-scratcher. Clearly, it is interpreting the accidental hex characters, but how does it decide which ones to use where?

This is one of those fascinating cases where a black box reveals something of its insides through how it behaves when broken. Neurologists study people with head injuries for similar reasons!