Why do weird things in font color attribute produce real colors?

I'm teaching a jr. high/high school web programming class, and we're starting with simple elements and attributes like font and color before moving on to CSS. I know color is deprecated and font is not included in HTML5, but for teaching purposes, I find it convenient to start with simple HTML tags and work our way up to CSS. The students get a lot of joy out of being able to change colors on a page during the first week of class. (I also teach them marquee and blink in week 1, but inform them that if they ever use them again, they will lose points).

One of the students started submitting homework with odd things in the color attribute values, like "Skittles" or "Spiderman". I started experimenting with this and discovered that just about anything you put into the color="" attribute on the font tag produces some sort of color. And it appears that the color is consistent across the latest versions of IE, Firefox, Chrome, Opera, and Safari.

I have discovered that putting "LuckyCharms" in as a CSS color DOES NOT WORK. It only seems to work where colors are expected in HTML attributes, for example font color="LuckyCharms", or body bgcolor="LuckyCharms".

I'm trying to explain to my class why this happens, and so far I haven't been able to make sense of it, or to Google a good answer. It would appear that it's being interpreted as a color code, but I can't make sense of how.

UPDATE: After some trial and error, I have determined a 5-step algorithm (using the link provided) to convert pretty much any string into the corresponding hex color. I will provide the algorithm here for the edification of future visitors:

1. Change each non-hex character to a 0.
2. Add 0's to the string until its length is a multiple of 3.
3. Divide string into 3 equal parts.
4. While the length of the sub-strings is greater than 2, and all three of the sub-strings begin with a 0, remove the leading 0s from each string.
5. If the length of the sub-strings is still greater than 2, then truncate each substring to 2 characters.

That's it, put the substrings together and you've got your hex color code. I have verified this algorithm with about 20 different samples and compared the results using the Firefox ColorZilla add-on color picker.

Note that in this case, the rules ARE indeed specifically stated in the link specified in one of the answers and will be adhered to by all browsers. So it is something you can count on to work in any browser (should you really want to use funny color names).

The HTML 5 specification includes the rules for parsing legacy colours.

They are rather long, and are designed to allow browsers to be consistent about how they handle broken code.

Very interesting. Seems as though the browser will interpret any character it can (a-f) and leave the rest to be 0's if it can't match. For instance:

Spiderman
 00DE0 A

Still needs more experimenting though.

This is an intriguing question.

Through brief experimentation, I've found that "Luck" produces the same color (to my eyes, anyway) as "LuckyCharms" but "LuckBeALady" gets you a darker shade, while "LuckBeALadyTonight" is bluer.

BTW, my first thought was that it was acting on the recognizable hex characters, but that turns "LuckyCharms" into cca, which rendered black. Combinations of 0's and the hex chars, as Madara Uchiba suggests, failed to render the same grass green as "LuckyCharms"

Don't have an answer tho.

The basic answer for what is expected to happen is "it depends on the browser". One of the problems with previous versions of HTML before 5 is that it is unspecified what happens when non-standard HTML is encountered by the browser. The interpretation from @Madara Uchiha is one example of how a browser might interpret the color specification, but it's just as allowable, standards-wise, for the browser to crash or to eject the CD tray or to change the resolution of your monitor to 400x300 px. Of course, this is not ideal - so what you're seeing is one programmer's idea, at one time, as to what should happen if a non-standard HTML color specification is encountered.

The reason it doesn't happen with CSS is that it's a different parser interpreting the color. This same parser interprets the color whether it's inline CSS or in a linked-in CSS document. CSS does define what happens to an improper value when it is encountered: it is ignored, and does not affect the document at all.

I would say this is a good time to talk to the class about standards compliance, as this is a critical field of understanding for students - and some professionals I have the misfortune to know. When they say, "But color Skittles works just fine", you can tell them that it works fine when they look at it, but it's entirely possible that it would crash their instructors' browser, earning them a big fat F. That's as close to a real-world scenario as you can get, when some of us have to give up our weekends because at demo time somebody else's crappy code doesn't work correctly.

I ain't bitter though. Mostly :)