[css-ui] Should we drop 'outline-color: invert'

[frivoal]

The outline-color property has an invert value, which specified as being the initial value. More than a color as such, it calls for inversion of the color of the underlying pixels.

This value has been in the spec for the longest time, and was implemented in multiple browsers, but these browsers are pre-blink Opera, IE, and pre-blink Edge. No current browser supports it. As I understand it, this is generally considered too hard to do given how modern compositors work.

The spec does account for the fact that some browsers don't/won't support it:

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 it must reject that value at parse-time, and the initial value of the outline-color property is the currentColor keyword.

We could keep it (a little complexified by the indirection via auto introduced by #7761). But is it worth it? If this is something we're moving away from, maybe it's time to drop it from the spec?

At the same time, the intent of that value does remain as relevant as it's always been: since outlines are important for accessibility, making sure they're always visible is desirable, and inverting the underlying color will achieve that in the overwhelming majority of scenarios.

So, is this a desirable hook for a useful behavior that someone some day may want to implement again, or is it an irrelevant leftover from times gone by?

[litherum]

I believe that color inversion is unimplementable in the presence of compositing layers

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Should we drop 'outline-color: invert', and agreed to the following:

• RESOLVED: drop outline-color:invert

The full IRC log of that discussion

<TabAtkins> florian: The outline property is used for many things. Some a11y, some decorative
<TabAtkins> florian: Because it's often used for focus indicators, which are v important to see
<TabAtkins> florian: an early notion was that the default behavior would be to invert the pixels of th eoutline, so it's always a different color from what's underneath and always visible
<TabAtkins> florian: Not entirely true against medium gray, but it does work in most situations
<TabAtkins> florian: This used to be implemented in Opera and IE, but modern browsers have a compositing system that works badly with this, and nobody implements it
<dbaron> It was implemented in Gecko but dropped, I think as of Firefox 3.
<TabAtkins> florian: We have a way to defer to the native platform, which can do whatever it wants for contrast
<TabAtkins> florian: We also have stripes() which can do black+white so it's always visible
<TabAtkins> florian: But this "invert" has become fiction
<TabAtkins> florian: So is this still useful that we just happen to not do now? If so, should we define how to fallback?
<TabAtkins> florian: Or is this a relic of the past that we should remove?
<ntim> q+
<matatk> q+
<astearns> ack ntim
<emilio> q+
<TabAtkins> ntim: I think currentcolor is actually better than invert in that people usually ensure text color contrasts with the bg
<ydaniv> q+
<TabAtkins> ntim: so it works reasonably well
<florian> q?
<TabAtkins> ntim: So I think "invert" should be deprecated in favor of just recommending currentcolor as default
<astearns> ack emilio
<TabAtkins> emilio: currentcolor doesn't work in various cases wher ethe outline is outside the element
<jensimmons> Emilo is too far from a mic to be understandable
<TabAtkins> emeyer: like drawing a ring around a button, you have to contrast against the surrounding bg, not the element's bg
<emeyer> s/emeyer/emilio/
<TabAtkins> emilio: In current browsers, "auto" does the right thing, it draws some accent color or something
<emeyer> q+
<astearns> ack matatk
<TabAtkins> emeyer: So given there's no prospects to implement "invert", I support removing it
<emilio> s/or something/and some contrasting color
<TabAtkins> matatk: a few things
<emeyer> s/emeyer/emilio/
<TabAtkins> matatk: First, there are some brightness and invert filters in OSes
<TabAtkins> matatk: invert color was cheap; but we really wanted invert brightness and preserve the color
<TabAtkins> matatk: (acknowledging that inverted brightness of gray is still gray)
<TabAtkins> matatk: Now time has moved on and we outline thru different means
<florian> q?
<TabAtkins> matatk: Separate point, something I see a lot in audits is you can have a good focus on a button and it's usually great, like a blue glow, but then they'll put it on a blue background and forget to cahnge it
<TabAtkins> matatk: So removing something that's a fiction isn't a bad policy; this isn't realistic to bring back to solve that dev problem.
<emilio> ack emilio
<TabAtkins> matatk: So as long as there are other ways to solve it
<astearns> ack ydaniv
<TabAtkins> ydaniv: +1, that's what I want to say. invert is either a hack or a relic of what we have today with color-scheme
<astearns> ack emeyer
<TabAtkins> ydaniv: now we have other ipmlementations so probably not needed
<TabAtkins> emeyer: i'm tentatively in favor of dropping as fiction
<TabAtkins> emeyer: As was described, this was meant to make outlines visible (theoretically) regardless (ignore gray)
<TabAtkins> emeyer: Would be interested to hear what is the best thing to do about outlines
<emilio> q+
<emilio> q- later
<TabAtkins> emeyer: brightness inverter, contrast mechanisms, to make it always be in contrast with the background pixels
<TabAtkins> emeyer: I have run into this problem where someone put the blue outline on the blue background
<ntim> q+
<TabAtkins> emeyer: Or big outline, becaus eit's not layout it pushes into adjacent regions and looks bad
<TabAtkins> emeyer: So wanna know the ideal outcome
<TabAtkins> Janina: I know there's major interest in WCAG 3 to get a better understading of contrast
<florian> q?
<TabAtkins> Janina: There may be some bac kand forth on this, they're working on the topic
<astearns> ack dbaron
<Zakim> dbaron, you wanted to comment on inverting brightness
<matatk> q+
<TabAtkins> dbaron: brief comment on inverting brightness
<TabAtkins> dbaron: a little skeptical it'll give good results enough
<TabAtkins> dbaron: human perception of lightness is mostly in the green
<TabAtkins> (the spread is roughly 2/5/1 in r/g/b)
<TabAtkins> dbaron: So if you invert lightness on blue while preserving color you get blue and black which is still bad contrast
<astearns> ack emilio
<TabAtkins> emilio: not an a11y professional, but i think "auto" gives you what you want in 99% of cases
<TabAtkins> emilio: Can construct some artificial cases so the browser outline just happens to overlap weirdly...
<TabAtkins> emilio: But I've never seen these cases in practice
<astearns> ack emilio
<florian> q+
<TabAtkins> ntim: I guess one idea is something akin to "auto"
<TabAtkins> ntim: Like a double-color outline, black and white
<TabAtkins> emilio: that's "auto" in firefox
<TabAtkins> fantasai: and that's the exact reason we added stripes()
<astearns> ack ntim
<astearns> ack matatk
<TabAtkins> matatk: it sounds like we have an action to consider this issue
<TabAtkins> matatk: discuss it with Paul and APA and our colleagues in ARIA
<TabAtkins> matatk: and bring developments to your attention. happy to do that
<astearns> ack florian
<TabAtkins> florian: My feeling is that the conclusion is that because we have both, thru "auto", the ability to let the browser do smart things, and with stripes() the author can manually do good outlines...
<fantasai> +1
<emilio> +1
<TabAtkins> florian: So both auto and manual are covered, and "invert" is fiction, we can just remove it
<TabAtkins> astearns: hearing unanimity
<dbaron> +1
<TabAtkins> RESOLVED: drop outline-color:invert

[Loirooriol]

For reference, some previous discussion about this in #423