Re: [csswg-drafts] [css-ui] Should we drop 'outline-color: invert' (#9199)

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

* `RESOLVED: drop outline-color:invert`

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9199#issuecomment-1721522640 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 15 September 2023 16:07:30 UTC