The testcase pointed to in the URL field demonstrates a way in which the css color parsing is too relaxed. In particular, hexidecimal color values without a leading # should be illegal. This test passes in Firefox 2, IE7 and Opera 9, but not in either shipping Safari or WebKit ToT.
Try the same test without the doctype (in quirks mode). Probably a quirk that isn't properly qualified.
(In reply to comment #1) > Try the same test without the doctype (in quirks mode). Probably a quirk that > isn't properly qualified. You are correct. In quirks mode Firefox, IE and Opera, the line does get successfully parsed.
Created attachment 12271 [details] testcase (strict mode)
Created attachment 12272 [details] testcase (quirks mode)
Created attachment 12336 [details] First attempt I figured out the Format substitution (http://trac.webkit.org/projects/webkit/changeset/17700) broke color parsing like color: 33FFFF. Related is handling of FF33333, as shown by the testcases for this bug. This patch should fix both. Cheers, Rob.
Comment on attachment 12336 [details] First attempt Looks fine, r=me. + if (Color::parseHexColor(name, rgb) && !strict) return true; It would be nice to not even parse in the strict case. Just reverse the two halves of the &&. + static RGBA32 parseColor(const String&, bool = false); Should have the name strict here, since bool along doesn't make it clear what the parameter is. + static bool parseColor(const String&, RGBA32& rgb, bool); Ditto.
Landed in r18722.