- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Wed, 3 Dec 2014 08:49:33 -0800
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Florian Rivoal <florian@rivoal.net>, www-style list <www-style@w3.org>, Tantek Çelik <tantek@cs.stanford.edu>
Based on the methodology of changes we've been applying to CSS3-UI to get it CR exit ready (drop if no interop), (a) is the best answer. I can preserve the text around 'invert' somewhere like the wiki for CSS4-UI consideration if there is implementer interest in converging on it. Tantek On Tue, Nov 25, 2014 at 1:17 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Tue, Nov 25, 2014 at 3:24 AM, Florian Rivoal <florian@rivoal.net> wrote: >> Based on issue 42: https://wiki.csswg.org/spec/css3-ui#issue42 >> >> The outline-color property (http://dev.w3.org/csswg/css-ui/#outline-color) admits the value 'invert', and uses it as the initial value. The spec states this: >> >> "The computed value of 'invert' is 'invert'" >> >> as well as >> >> "Conformant UAs may ignore the invert value on platforms that do not support color inversion of the pixels on the screen. If the UA does not support the invert value then the initial value of the outline-color property is the currentColor [CSS3COLOR] keyword." >> >> Actual implementations are all over the place, as shown here: http://jsbin.com/timoqebuya/1/watch?css,output >> >> Firefox (33): >> - fails to parse 'invert' >> - uses 'black' as the initial value >> >> Chrome (39): >> - parses 'invert' >> - renders it as transparent >> - uses 'invert' as the computed value of 'invert' >> - uses 'currentColor' as the initial value >> >> Safari (8): >> - parses 'invert' >> - renders it identically to currentColor >> - uses the actual value of the rendered color as the computed value >> - uses 'currentColor' as the initial value >> >> IE (10): >> - parses 'invert' >> - renders it inverted >> - uses 'transparent' as the computed value >> - uses 'invert' as the initial value >> >> Opera (Presto): >> - parses 'invert' >> - renders it inverted >> - uses 'invert' as the computed value >> - uses 'invert' as the initial value >> >> So Presto is 100% spec compliant and supports inverted colors, and IE comes close except for a bug in computed value. >> >> The other browsers chose not to support inverted colors, but go about it in different ways, with Chrome being the worse behaviour, as you get invisible outlines when you wanted highly visible ones. I think the current spec is somewhat ambiguous, as it says to "ignore the 'invert' value", but isn't clear whether this means it should not be parsed, or something else. I suggest we pick one of the 2 following behaviours: >> >> a - Must fail to parse 'invert' and must use 'currentColor' as the initial value >> or >> b - Must parse 'invert', but must compute it to currentColor. Using 'invert' or 'currentColor' as the initial value makes no difference, so I suggest sticking to 'invert'. >> >> a is what firefox does, except that the initial value switches form black to currentColor. It is also probably what the spec's wording intends. >> >> b is what safari does, except the computed value of currentColor should be currentColor (as per http://dev.w3.org/csswg/css-color-3/#color0) rather than the corresponding color value >> >> I wouldn't object to either, but I have a preference for a, as it allows authors to use the cascade (or @supoorts) to specify a fallback when inversion is not supported, while b doesn't. > > Yes, if we're allowing implementions to not support the value, we > should require them to *not support the value*, including parsing. > (a) is the best answer. > > ~TJ
Received on Wednesday, 3 December 2014 16:50:50 UTC