- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 15 Jul 2011 11:51:53 -0700
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
Received on Friday, 15 July 2011 11:51:53 UTC