Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
On Fri, Jul 15, 2011 at 11:43 AM, Ian Hickson i...@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
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
On Friday 2011-04-08 13:54 -0700, Tab Atkins Jr. wrote: This doesn't match Webkit's behavior. Instead of steps 5 and 6, we just try to parse it as a CSS color. As I pointed out in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026449.html this isn't compatible with doing the following simultaneously: * using the algorithm given, which converts the values to colors at parse time * correctly handling dynamic changes of system appearance for the system color values Correctly handling dynamic changes of system appearance here would be a significant amount of work even if the algorithm here changed, and I'd really rather not add that support for a legacy feature, nor would I like to have an inconsistency between CSS and HTML as to whether system colors are dynamically updated. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla Corporation http://www.mozilla.com/ 턂
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
On Fri, Jul 15, 2011 at 11:57 AM, L. David Baron dba...@dbaron.org wrote: On Friday 2011-04-08 13:54 -0700, Tab Atkins Jr. wrote: This doesn't match Webkit's behavior. Instead of steps 5 and 6, we just try to parse it as a CSS color. As I pointed out in http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026449.html this isn't compatible with doing the following simultaneously: * using the algorithm given, which converts the values to colors at parse time * correctly handling dynamic changes of system appearance for the system color values Correctly handling dynamic changes of system appearance here would be a significant amount of work even if the algorithm here changed, and I'd really rather not add that support for a legacy feature, nor would I like to have an inconsistency between CSS and HTML as to whether system colors are dynamically updated. WebKit now matches the spec (and Firefox) anyway, so the issue is moot. ~TJ
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
On Fri, 15 Jul 2011, Tab Atkins Jr. wrote: 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? See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9847 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12372 Basically, it looks like IE does strip whitespace in some cases, the main difference is that it doesn't handle #123 the same as #112233. Since that would introduce an incompatibility with CSS, and since there was no interop on that case, I figured (based on input from Aryeh and dbaron) we might as well go with the sane behaviour. Interop isn't perfect here so there's not really any winning whatever we do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
On Fri, Jul 15, 2011 at 1:18 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Jul 2011, Tab Atkins Jr. wrote: 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? See: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9847 http://www.w3.org/Bugs/Public/show_bug.cgi?id=12372 Basically, it looks like IE does strip whitespace in some cases, the main difference is that it doesn't handle #123 the same as #112233. Since that would introduce an incompatibility with CSS, and since there was no interop on that case, I figured (based on input from Aryeh and dbaron) we might as well go with the sane behaviour. Interop isn't perfect here so there's not really any winning whatever we do. That's fine. I was just curious. Like I said, WebKit now matches the spec, so whatever. ~TJ
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
On Fri, Apr 8, 2011 at 10:26 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/8/11 1:54 PM, Tab Atkins Jr. wrote: In the legacy color parsing algorithm [...] 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 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.) -- Philip Taylor exc...@gmail.com
[whatwg] Accept full CSS colors in the legacy color parsing algorithm
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.) ~TJ
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
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 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. -Boris
Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm
On Fri, Apr 8, 2011 at 2:26 PM, Boris Zbarsky bzbar...@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=# and expecting it to be black. ~TJ
