Re: [css3-ui] interoperability of outline:invert (Issue 42)

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 Tuesday, 25 November 2014 21:17:54 UTC