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

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.

 - Florian

Received on Tuesday, 25 November 2014 11:24:34 UTC