- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Nov 2021 17:49:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color] [css-color-adjust] Consider reversing the resolution of #3847`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: [css-color] [css-color-adjust] Consider reversing the resolution of #3847<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/6773<br> <fantasai> emilio: We made system colors compute to themselves because wanted them to react to color-scheme<br> <fantasai> emilio: but that's not behavior any agent has, and when you do that you get lacking contrast if color scheme changes but you didn't change the bgcolor<br> <fantasai> emilio: not quite clear to me what Blink is doing<br> <fantasai> emilio: but, computing system colors to the keywords themselves also causes complexity<br> <fantasai> emilio: with interpolation, issues open since we resolved that<br> <Rossen_> q?<br> <TabAtkins> q+<br> <fantasai> emilio: So can we undo that resolution?<br> <fantasai> TabAtkins: A couple of points emilio made are present today regardless<br> <Rossen_> ack TabAtkins<br> <fantasai> TabAtkins: e.g. complexity of interpolating color, currentColor resolves at used-value time<br> <fantasai> TabAtkins: exact same case for system colors<br> <fantasai> TabAtkins: also has a point about needing to set system colors in pairs, and yes, you do, and spec says you should always do that<br> <fantasai> TabAtkins: it's very easy to get messed up and have bad colors if you don't, in general<br> <fantasai> TabAtkins: if we compute system colors and computed value time, then whenever color-scheme changes, in particular if you go across any embedding boundaries, shadow boundaries, they'll be messed up as well<br> <fantasai> TabAtkins: they'll assume in light mode and responsibly use system colors, get wrong colors inheriting in<br> <fantasai> TabAtkins: so I think the current specced behavior is the best<br> <fantasai> TabAtkins: chrome's behavior is weird and inconsistent right now, but once matches spec, I think it will be reasonable behavior<br> <fantasai> TabAtkins: and won't save any complexity but changing it<br> <fantasai> s/but/by/<br> <fantasai> emilio: Not about setting colors in pairs, but about changing color scheme<br> <fantasai> emilio: if ...<br> <fantasai> emilio: if you make system colors compute to themselves, forced-color-adjust: preserve-parent-color is like forcing to resolve their values, which is pretty odd<br> <fantasai> emilio: we're landing workarounds...<br> <fantasai> emilio: I disagree that this doesn't introduce complexity<br> <alisonmaher> q+<br> <fantasai> emilio: preserve-parent-color is literally working around this behavior<br> <fantasai> TabAtkins: ppc is about forced-color-adjust, where we want SVG to be able to opt out of being forced-colored, but still be able to respond to system colors coming in<br> <fantasai> TabAtkins: We have plenty of SVG in the wild that want to respond to outside color and set some of their own colors as well<br> <fantasai> TabAtkins: to work in forced color mode, need some way to tell whether receiving system color vs other color<br> <fantasai> emilio: not true, FF behaves correctly right now [...]<br> <fantasai> alisonmaher: ppc was a workaround due to handling forced-colors mode, not about system colors computing to themselves<br> <Rossen_> ack alisonmaher<br> <fantasai> emilio: to me, both are related. If don't preserve ??? then can't at used value time<br> <fantasai> alisonmaher: in Chrome we do implement this workaround. We also haven't shipped system colors computing to themselves yet<br> <fantasai> alisonmaher: Essentially piggybacking on top of, have an implementation where it computes to itself, so workaround with impl that hasn't shipped yet<br> <fantasai> Rossen_: so building on the capability but not exposed?<br> <fantasai> alisonmaher: yeah<br> <Rossen_> q?<br> <fantasai> emilio: We define system colors to compute to themselves<br> <fantasai> emilio: you need to implement forced-colors at used value time and vice versa<br> <fantasai> emilio: complexity comes from making both forced colors and system colors compute at used value time<br> <drott> fantasai: if we don't make the system colors compute to themselves<br> <drott> fantasai: if you switch scheme, it won't have any effect - which is not expected<br> <fantasai> emilio: Let's say have a dark background and background is Canvas<br> <fantasai> emilio: if you just change color-scheme you get illegible text<br> <fantasai> dbaron: if they don't compute to themselves, you run a restyle<br> <drott> fantasai: if you have an element that is color-scheme dark, inside one with color-scheme light<br> <drott> fantasai: are you going to have light or dark? or what's happening inside?<br> <drott> fantasai: if you move it out, you'd expect it to stay on that<br> <fantasai> fantasai: but it inherits different resolve colors depending on parent color scheme<br> <fantasai> fantasai: to get colors you expect, you can't rely on system colors inheriting, have to re-declare them when declaring color-scheme<br> <Rossen_> q?<br> <TabAtkins> Form what I can tell, emilio, you're saying that if authors don't set colors in pairs, they can get bad results. Is that right?<br> <fantasai> emilio: need to restyle anyway, need to set at least the backgrounds, so can't rely on inheritance otherwise get broken behavior<br> <fantasai> emilio: always need to set in pairs, but even if you do, but if you change color-scheme without setting any color then behavior is broken if they compute to themselves<br> <fantasai> emilio: because changing only foreground color and bg color doesn't change because not inherited<br> <fantasai> Rossen_: Given the complexity of these different combinations and where Chromium implementation is, in its inconsistent state, I propose we continue to work on this issue in GH<br> <chris_> "Authors may also use these keywords at any time, but should be careful to use the colors in matching background-foreground pairs to ensure appropriate contrast, as any particular contrast relationship across non-matching pairs (e.g. Canvas and ButtonText) is not guaranteed."<br> <fantasai> Rossen_: and once more implementers as well as others have a stable conclusion, can bring it back for resolution<br> <chris_> https://drafts.csswg.org/css-color-4/#css-system-colors<br> <fantasai> Rossen_: going in circles here trying to define expected behaviors<br> <fantasai> Rossen_: as well as what everyone is talking about<br> <fantasai> emilio: Yeah, agree, I think we're talking past each other a bit<br> <fantasai> Rossen_: ok, well thanks for opening issue<br> <chris_> Also "The following system color pairings are expected to form legible background-foreground colors:"<br> <fantasai> Rossen_: let's move on to next issue<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-965589425 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 November 2021 17:49:33 UTC