- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 8 Apr 2011 14:42:55 -0700
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 UTC