W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2011

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 8 Apr 2011 14:42:55 -0700
Message-ID: <BANLkTimwuMjgTKewiFZbLAvmQFACobmfaA@mail.gmail.com>
On Fri, Apr 8, 2011 at 2:26 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 4/8/11 1:54 PM, 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.
>
> But it does match other UAs....

I suspected it did; this just seemed like a half-useful difference.


>> 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.)
>
> 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.

I might agree with you here, now that I think about it more.  It would
make it easier for me to deploy my 4/8 hexit patch, since there *is* a
small compat cost in the form of people doing <font color="#00000000">
and expecting it to be black.

~TJ
Received on Friday, 8 April 2011 14:42:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:03 GMT