- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Apr 2021 22:08:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Ensuring selection foreground/background contrast`.
<details><summary>The full IRC log of that discussion</summary>
<Rossen_> Topic: Ensuring selection foreground/background contrast<br>
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/6150<br>
<TabAtkins> chrishtr: ::selection can set fg and bg color. What happens if they're not contrasty enough?<br>
<TabAtkins> chrishtr: If they're the same, you can't read the text<br>
<TabAtkins> chrishtr: For that reason, wk/chrome has special code to invert one of them in that case<br>
<TabAtkins> chrishtr: There's at least one site reported as "can't see selections" in Gecko, because fg and bg were both white, and dev might not have noticed it in testing because wk/chrome intervene and fix it<br>
<TabAtkins> chrishtr: so should we remove the intervention, or require it?<br>
<chris> q+<br>
<Rossen_> ack sanketj<br>
<Rossen_> ack fantasai<br>
<TabAtkins> fantasai: So someone was using white ::selection 'background' and 'color'. This works in wk/chrome because neither uses an opaque bg<br>
<TabAtkins> fantasai: Gecko, following the spec, paints the color as specified<br>
<TabAtkins> fantasai: So that brings up an interesting question of - we need to decide either the specified bg is what's used, or the bg is modified in some way<br>
<TabAtkins> fantasai: If UA's differ, you'll get these interop issues<br>
<TabAtkins> fantasai: They're either assuming the tranparency is there, or assuming it's not, and it might not work in the other cases<br>
<TabAtkins> fantasai: So we need to have interop on the alpha of the bg color in ::selection<br>
<chris> CSS Color 4 "The following system color pairings are expected to form legible background-foreground colors ... Highlight background with HighlightText foreground.<br>
<TabAtkins> chrishtr: Our code is flipping the color, definitely - I checked<br>
<chris> q?<br>
<TabAtkins> chris: In Color 4, certain combos of system colors are required to be legible<br>
<leaverou_> q?<br>
<TabAtkins> chris: One of those pairings is HighlightColor and HighlightBackground<br>
<leaverou_> q+<br>
<fantasai> WebKit is using semi-transparent white, though, and that's probably what the author was expecting<br>
<TabAtkins> TabAtkins: This is about author-chosen colors tho<br>
<TabAtkins> chris: Ah, sorry<br>
<myles> q+<br>
<TabAtkins> leaverou_: I'm skeptical about UA intervening in author choices here...<br>
<TabAtkins> leaverou_: Sounds like this issue happened because author was setting bg and not text?<br>
<TabAtkins> fantasai: They were setting both<br>
<Rossen_> q?<br>
<Rossen_> ack chris<br>
<Rossen_> ack leaverou_<br>
<TabAtkins> leaverou_: Wonder if we could set better defaults? Set default bg to always contrast with text color using Color 5 colors<br>
<fantasai> This is a case where the author explicitly asked for white text and white background<br>
<fantasai> https://bugzilla.mozilla.org/show_bug.cgi?id=1589539#c5<br>
<TabAtkins> myles: We think the spec should say *at least* that UAs should do something to make sure text is legible when highlighted<br>
<TabAtkins> myles: No opinion on how far the spec shoudl go<br>
<TabAtkins> myles: If the spec had an algo, that's fine<br>
<TabAtkins> myles: If the spec just says "UA must do something", that's fine with us too<br>
<TabAtkins> florian: Gets interesting when fg and bg are coming from different pseudos<br>
<TabAtkins> florian: As an author you ought to set fg and bg together, but you can make this mistake<br>
<TabAtkins> florian: So ahving a req that the UA must ensure the topmost fg and bg colors must contrast...<br>
<TabAtkins> florian: Just making sure it's clear this can happen accidentally from different pseudos interacting, and that should be considered<br>
<TabAtkins> fantasai: Cause of the bug:<br>
<TabAtkins> fantasai: Person filing was assumign a semi-transparent whitewash with white text<br>
<TabAtkins> fantasai: Chrome used to do that<br>
<TabAtkins> fantasai: In Moz, it was rendering as solid white on white<br>
<leaverou_> maybe we should adopt the previously proposed currentBackground keyword? Then UA default could be color: color-contrast(to 4.5 currentBackground vs white, black); (or appropriate system colors)<br>
<fantasai> https://bugzilla.mozilla.org/show_bug.cgi?id=1589539#c5<br>
<TabAtkins> fantasai: Author literally wrote ::selection { color: white; background: white; }<br>
<TabAtkins> fantasai: They were expecting a particular rendering, which they were getting in Chrome and WebKit, but not Gecko, bc both were applying magic opacity<br>
<TabAtkins> fantasai: So I think ti's harmful for some browsers to have magic opacity and osme not<br>
<leaverou_> agreed with fantasai that if author specifies both, they should be respected<br>
<TabAtkins> fantasai: So we need to align on some behavior here.<br>
<TabAtkins> florian: I agree the state we're in is bad. Your proposal is one possibility. Myles's too - require all browsers to require legibility, but not specify how<br>
<TabAtkins> florian: So if you're in a non-legible combo (for any reason, including the browser applying magic opacity or wahtever), the UA must change something to make it legible.<br>
<TabAtkins> florian: Mandating one algo woul be great, but not sure we can do that.<br>
<TabAtkins> fantasai: So example: authors choose a semi-transparent color for the bg. It's just enough to show a selection, but not enough to be probablematic against the bg<br>
<TabAtkins> fantasai: In WK browsers, they'll compound the opacity, so it's even more faint of a bg. No legibility problem, but there's no longer a visible highlight, which is another problem.<br>
<TabAtkins> fantasai: Now author has a problem despite making good choices originally.<br>
<TabAtkins> fantasai: Whether we adjust or not is fine, but having it work differently across browsers is problem.<br>
<TabAtkins> florian: So from Apple pov, if we specify a particular transparency, is that a problem for y'all?<br>
<TabAtkins> smfr: Unsure if we have an answer to that. We want our selection to match the OS convention, so there's magical opacity<br>
<TabAtkins> smfr: Dont' know if we'd be willing to turn off magic opacity in some cases, seems hard...<br>
<TabAtkins> florian: If we specify exactly *your* opacity, woudl that work? Or do you reserve the right to change the exact method?<br>
<TabAtkins> smfr: I don't think it's just opacity, there's a blend mode involved too<br>
<TabAtkins> florian: So your behavior is too magic to spec?<br>
<TabAtkins> smfr: Could probably spec it, but not all platforms might want to match the Mac OS conventions<br>
<gregwhitworth> I agree with fantasai there<br>
<TabAtkins> fantasai: Don't think people have problems with amtching OS conventions by defautl, just when the author says something specific, it should be predictable<br>
<fantasai> s/predictable/predictable across platforms/<br>
<TabAtkins> smfr: Generally we solve this by adding a CSS property that lets authors opt out of the correction<br>
<TabAtkins> fantasai: We do have a long-standing request for a bg-opacity property<br>
<TabAtkins> florian: So a default value of "auto" that can do magic things in some OSes?<br>
<TabAtkins> fantasai: Maybe.<br>
<Rossen_> q?<br>
<TabAtkins> florian: I think we should explore more in this area.<br>
<TabAtkins> florian: We *will* get interop problems if we don't ahve something like this.<br>
<TabAtkins> Rossen_: So should we take this back to the issue?<br>
<hober> q+<br>
<hober> q- myles<br>
<Rossen_> ack hober<br>
<TabAtkins> hober: I think this action sounds reasonable.<br>
<TabAtkins> hober: Could we resolve on the direction to go in - to require UAs to ensure there be sufficient contrast, exact details TBD?<br>
<TabAtkins> hober: UAs do need to do something, right?<br>
<TabAtkins> florian: I think elika pointed out that if you do that, you can hit the opposite situation, where a good fg/bg contrast gets magicked into a lack of contrast between selection and page bg?<br>
<TabAtkins> hober: I think we can word the reoslution to avoid that<br>
<TabAtkins> hober: I hope we can end up with simple details<br>
<TabAtkins> hober: We just shouldn't punt on this, right?<br>
<TabAtkins> fantasai: Yes, shouldn't punt. I just think I can throw a lot of wrenches into this. ^_^<br>
<TabAtkins> fantasai: [another example]<br>
<TabAtkins> fantasai: So there will be a lot of thought needed for the details<br>
<TabAtkins> fantasai: And I think we should start be having an ability for authors to specify a more exact interop<br>
<gregwhitworth> if you do it post composite you could but it would be a bad perf path but would ensure contrast so the text scenario would result in no adjustment by the UA<br>
<TabAtkins> florian: I think we overall agree, just resolving to "browsers must do X" is a little premature at the moment<br>
<fantasai> [another example] = author intended transparent selection background (so UA detection of no contrast between selection bg and page would be a problem) and is using color change on the text to indicate the selection<br>
<TabAtkins> <br duration="15min"><br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6150#issuecomment-816262313 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 April 2021 22:08:35 UTC