[whatwg] Accept full CSS colors in the legacy color parsing algorithm

Fri Jul 15 11:51:53 PDT 2011

On Fri, Jul 15, 2011 at 11:43 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 8 Apr 2011, Tab Atkins Jr. wrote:
>> In the legacy color parsing algorithm
>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value>,
>> steps 5 and 6 concern CSS color names - 'transparent' should raise an
>> error, and color names should be respected.  All other CSS color
>> syntaxes, though, such as the rgba() function, are just passed through
>> to the rest of the algorithm and appropriately mangled.
>>
>> This doesn't match Webkit's behavior.  Instead of steps 5 and 6, we just
>> try to parse it as a CSS color.  If we succeed, we use that color.
>> Otherwise, we chunk it into the legacy parsing algorithm and do what the
>> spec says.  So, for example, <font color=rgba(255,0,0,.5)>foo</font> is
>> actually displayed as partially-transparent red instead of dark green
>> (following the algorithm mangles the string into #050).
>>
>> Could we change those two steps to just say "If keyword is a valid CSS
>> color value, then return the simple color corresponding to that value."?
>> (I guess, to fully match Webkit, you need to change the definition of
>> "simple color" to take alpha into account.)
>
> On Fri, 8 Apr 2011, Boris Zbarsky wrote:
>>
>> But it does match other UAs....
>>
>> Do you have web compat data here?
>>
>> I would much rather stick with color parsing as defined in HTML4 modulo
>> the "not a color name, treat it as a hex color even if it doesn't start
>> with '#'" quirk than replace the "is it a color name?" test with a "does
>> it parse as a CSS color?" test.
>
> On Wed, 13 Apr 2011, Philip Taylor wrote:
>>
>> I don't know if this is relevant or useful but anyway:
>> http://philip.html5.org/data/font-colors.txt has some basic data for
>> <font color> values, http://philip.html5.org/data/bgcolors.txt for <body
>> bgcolor>. (Each line is the number of URLs that value was found on (from
>> the set from http://philip.html5.org/data/dotbot-20090424.txt), followed
>> by the XML-encoded value.)
>
> Looks like there are values that would be affected by this change.
>
> I've left it as-is. I think compat here is vastly more important than
> adding new capabilities, since this is only used for legacy features.

I recently patched WebKit to match the spec anyway, so that's fine.  ^_^

I'll note, though, that the spec algorithm seems to be Firefox's
behavior, which differs in a few significant points from IE's.  In
particular, IE doesn't strip whitespace from the color, doesn't have
the same "truncate at 128 bytes" behavior, and doesn't recognize a
3-digit hex color as a CSS color (instead parsing it with legacy
rules).

I doubt it matters too much, but was there any particular reason you
went with Firefox over IE here?

~TJ