Re: [csswg-drafts] [css-color] [css-color-adjust] Make system colors fully resolve (but flag they were system colors) thus reversing the resolution of #3847 (#6773)

The CSS Working Group just discussed `[css-color] [css-color-adjust] Make system colors fully resolve (but flag they were system colors) thus reversing the resolution of #3847`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dbaron> Topic: [css-color] [css-color-adjust] Make system colors fully resolve (but flag they were system colors) thus reversing the resolution of #3847<br>
&lt;dbaron> github: https://github.com/w3c/csswg-drafts/issues/6773<br>
&lt;dbaron> Agenda is https://lists.w3.org/Archives/Public/www-style/2022Mar/0005.html<br>
&lt;dbaron> fantasai: We delayed this to give me a chance to reread the whole conversation... which I did.  What I understand about this issue is that it was raised because switching color scheme shouldn't cause system colors to change when they're intherited.  I think behavior of having system colors switch along with color scheme makes sense.  Why would you switch color scheme if you're not changing colors?<br>
&lt;dbaron> fantasai: Then an argument that making ??? with 18 different combinations of colors is unwieldy.  I'd take that as "too hard to implement".<br>
&lt;emilio> q+<br>
&lt;TabAtkins> q+<br>
&lt;dbaron> fantasai: Then there were arguments about resolving system colors at used value time: (1) makes some transitions issues go away and (2) setting forced-color-adjust:none on subtree reverts to colors that author specified.  If we take this change then forced-colors would work only on non-inherited colors.  That could cause contrast problems.<br>
&lt;dbaron> fantasai: There's arguments in both directions.<br>
&lt;fantasai> s/???/forced-color-adjust: none/<br>
&lt;Rossen_> ack emilio<br>
&lt;dbaron> emilio: There's another argument for ... color-scheme doesn't behave like you want it to behave.  But regarding forced-color-adjust:none, that seems like a better behavior.  At least, we were proposing adding a new value just to do the thing you get when you resolve system colors at computed value time.  We were planning to make that default in SVG, which is the obvious place to use forced-color-adjust:none.  So I'm not sure the behavior for<br>
&lt;dbaron> forced-color-adjust:none with used value time forcing is better.<br>
&lt;Rossen_> ack tantek<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/6773#issuecomment-1069295596<br>
&lt;dbaron> TabAtkins: In first part of fantasai's response, fantasai argues against inheriting a color not respecting a color scheme.  I think you should reconsider.  I switched to emilio's viewport because if an inherited system color repsects a change in color scheme... this leads to the a11y problem of text color and background color not being set as a pair.  If background is transparent... will be bad when you use your text color with other<br>
&lt;dbaron> background color.<br>
&lt;dbaron> TabAtkins: If you use the system colors explicitly, inherited text will by default wrong if it respects color scheme changes.  I think that's a mistake.<br>
&lt;Rossen_> ack fantasai<br>
&lt;emilio> q+<br>
&lt;dbaron> fantasai: The color-scheme doesn't switch at a boundary randomly... the author has to explicitly say they're switching the color scheme.  Why are they changing it if they're not making other color changes too?  I'd expect author to use these things in coordinatiotn.<br>
&lt;tantek> +1 fantasai<br>
&lt;Rossen_> fantasai, what about tools? F12 is supporting forced-colors effect for debugging/testing<br>
&lt;dbaron> fantasai: On the flip side, forced-color-adjust: none problem:  if you have a subtree where you want the colors to be the ones I specified and you set forced-color-adjust:none, and the browser only turns off forced-color-adjust for some of your colors, that's not expected behavior.  You tried to turn it off and it doesn't turn it off.  (You might not notice depending on your colors.)<br>
&lt;Rossen_> q<br>
&lt;dbaron> fantasai: I think the difference here is there's no good use case for an author setting color scheme and not setting other colors, but there are reasons the author should expect that setting forced-color-adjust:none actually turns it off.<br>
&lt;dbaron> fantasai: I think contrast issue you're concerned about is ???<br>
&lt;dbaron> TabAtkins: I think you're off... when author sets forced-color-adjust.. ??? ... either author is setting some colors and letting others through which violates a11y guidelines, or they're seting all the colors and it doesn't matter.<br>
&lt;dbaron> fantasai: They know what color is inheriting through.<br>
&lt;dbaron> TabAtkins: There's no guarantee they know what the colors are from the outside, if forced-color is happening, or if they're distributing a component.<br>
&lt;dbaron> TabAtkins: So the inherited color is potentially a mystery.  They're potentially mixing it with known colors (bad), or overriding all.  I think people still do the bad case, and we should give a more-likely-accessible result.<br>
&lt;fantasai> Plenty of authors write pages where they set the background on lots of elements, but only set the text color on the root<br>
&lt;TabAtkins> (This convo did happen in the issue, we're re-arguing it.)<br>
&lt;fantasai> This is normal and expected, and it's not a problem.<br>
&lt;dbaron> Rossen: Sounds like we're probably not ready to resolve, but let's hear from fantasai and emilio.<br>
&lt;dbaron> emilio: [we can hear him but he can't hear us]<br>
&lt;Rossen_> emilio, we can hear you!<br>
&lt;fantasai> But it *is* a problem if you set `forced-color-adjust: none` on an element.<br>
&lt;emilio> lol<br>
&lt;fantasai> because the color you've inherited is no longer the one you expected.<br>
&lt;emilio> brb<br>
&lt;dbaron> fantasai: It's normal and common for authors to set text colors on root element, and set background colors on other elements without resetting the text color.  There's no problem with it, because you know what color is inherited because you control the whole page.  This doesn't hold for components, but not all pages are component-based.<br>
&lt;Rossen_> ack emilio<br>
&lt;dbaron> emilio: So I was going to argue the same thing as TabAtkins... that doing it at computed value causes contrast issues by default.  Specifying color-scheme may not end up in a color scheme change... may specify normal.  It's not clear that authors will realize their colors are wrong.<br>
&lt;dbaron> (was there a "no" I missed?)<br>
&lt;TabAtkins> Right, even in color-scheme changes authors can't necessarily predict the color that they'll receive.  So no, this is bad *even in an entirely first-party situation*.<br>
&lt;dbaron> Rossen: Continue discussion in github issue, bring back for resolution next week.<br>
&lt;tantek> +1 Rossen<br>
&lt;fantasai> scribenick: fantasai<br>
</details>


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


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

Received on Wednesday, 16 March 2022 16:50:40 UTC