- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Nov 2024 17:54:53 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-color-adjust] Should forced-colors support `color-mix()`?``, and agreed to the following: * `RESOLVED: Close no change.` <details><summary>The full IRC log of that discussion</summary> <JakeA> I'm sad that that was timeboxed so aggressively vs the bikeshedding<br> <TabAtkins> ChrisL: everyone implements color-mix() with system colors. we use rgb value of those colors<br> <TabAtkins> ChrisL: all good<br> <TabAtkins> ChrisL: but what to do in forced colors mode?<br> <TabAtkins> ChrisL: spec say scomputed value is the mixture, used value is overriden by a system color<br> <TabAtkins> ChrisL: that's what chrome does. firefox lets you mix it, so you can do opacity variations/etc<br> <TabAtkins> ChrisL: should this be allowed?<br> <emilio> q+<br> <astearns> ack bramus<br> <kbabbitt> q+<br> <TabAtkins> emilio: i implemented firefox behavior. i think it's reasonable, it was a specific request from othe rengineers on firefox desktop<br> <TabAtkins> emilio: i have more concerns about relative colors, which have the same kind of issue<br> <TabAtkins> emilio: but i think as long as the arguments are system colors or transparent, it's reasonable to allow<br> <TabAtkins> emilio: but i don't care too strongly<br> <astearns> ack emilio<br> <astearns> ack kbabbitt<br> <TabAtkins> kbabbitt: as i commented in the issue, the goal of forced colors is to give the user control over the contrast settings that they're seeing<br> <TabAtkins> kbabbitt: so i think mixing them and reflecting that valu eint he computed result is fine, but what actually gets presented to the user should be reflective of their chosen palette, which precludes mixed colors<br> <lea> q+<br> <ChrisL> s/valu eint he/value in the<br> <TabAtkins> kbabbitt: for UI concerns, i have a brief example in the issue, there's other ways to reflect the states that someone might use mixed or partially transparent styles for. using different outline styles, for example. i've seen this in high-contrast UIs to work around it being limited<br> <TabAtkins> emilio: that puts a lot of burden on authors, tho.<br> <TabAtkins> emilio: a lot easier to say, like, "my buttons have system colors on fg and bg, and hover states are variations of that"<br> <TabAtkins> emilio: a lof of generic CSS I've seen uses currentcolor and transparent<br> <TabAtkins> emilio: don't see the point of allowing currentcolor and not system colors<br> <TabAtkins> emilio: if you don't allow it, you put the burden on authors to change the whole stylesheet, rathe rthan things just working<br> <TabAtkins> q+<br> <astearns> ack lea<br> <TabAtkins> lea: what exactly is the proposed behavior if we don't allow it? invalid at parse time? how are authors supposed to deal, use MQs?<br> <TabAtkins> lea: i was wondering, instead of disallowing certain things, can we just allow anything and cast the result to the closet allowed color at used value time?<br> <kbabbitt> q+<br> <TabAtkins> lea: that seems better for DX, unsure if feasible<br> <TabAtkins> ChrisL: that's pretty much what the spec says, that you pick the closest allowed color<br> <TabAtkins> ChrisL: closest not being parituclarly well defined<br> <TabAtkins> lea: then i'm missing something, why wouldn't we allow color-mix()?<br> <TabAtkins> ChrisL: we do allow color-mix(), the question is what to do with the result<br> <TabAtkins> ChrisL: use the computed vlaue, or one of the forced values<br> <TabAtkins> lea: i'd expect it to produce the result, then see which allowed color it's closest to<br> <TabAtkins> emilio: in firefox there's no partiuclarly well-defined notion of what's "closest"<br> <TabAtkins> emilio: firefox actually give syout he mixed color and you can use it<br> <TabAtkins> lea: i'd be surprised if the spec doesn't ahve a well-defined notion of closet<br> <ChrisL> " the UA determines the appropriate forced system color—which should match the color that would result from an empty author style sheet whenever all of the element’s affected properties are likewise UA-determined."<br> <TabAtkins> florian: regardless of that, i think the spec and chrome do snap the result to the closest color; the question is whether we do chrome or firefox behavior<br> <ChrisL> ie handwaving<br> <TabAtkins> emilio: i think chrome probably treats it something closer to revert<br> <TabAtkins> florian: you mean chrome doesn't pick the closest color, it just chooses something?<br> <lea> oof. We should *at least* provide a way to determine closest, even if non-normative<br> <TabAtkins> emilio: I'd be surprised, yes. i think it's more like if you use any ohter non-allowed color<br> <TabAtkins> kbabbitt: I expect what emilio said is correct. Blink sees the color-mix(), sees it's not a system color, and substitutes<br> <astearns> ack TabAtkins<br> <ChrisL> q?<br> <fantasai> TabAtkins: With regards to emilio's point about being able to do generic stylesheets that slightly change colors, part of the deal is, that subtle distiction would be invisible to users of forced colors mode anyway<br> <fantasai> TabAtkins: those authors are using identical colors in such a state anyway<br> <emilio> q+<br> <fantasai> TabAtkins: Those authors should be doing something different in forced colors mode regardless<br> <astearns> ack kbabbitt<br> <TabAtkins> kbabbitt: +1 to what Tab just said<br> <fantasai> kbabbitt: +1 to what Tab said<br> <astearns> ack emilio<br> <TabAtkins> kbabbitt: also prirority of constituences, should lean to user preference for what they're seeing than author convenience<br> <TabAtkins> emilio: i see two kinds of forced color users. ones that need a specific color palette, and ones that just want one.<br> <TabAtkins> emilio: depending on which user, the color-mix() works great for the latter<br> <florian> q?<br> <florian> q+<br> <kbabbitt> q+ to respond on the "need" vs "want" use cases<br> <lea> I'm still very confused. E.g. what is the result of `color: color-mix(in lab, allowedColor1 0%, allowedColor2);`? It should not be different than `color: color-mix(in lab, allowedColor1, allowedColor2 100%);` or `color: allowedColor2`<br> <TabAtkins> emilio: I agree you need to do something with more contrast for the former case, but allowing color-mix() doesn't preclude that. It does make life easier for the second class.<br> <astearns> ack florian<br> <TabAtkins> astearns: I think user needs should override user wants<br> <TabAtkins> florian: the primary intent of this feature is a11y, not theming<br> <TabAtkins> florian: it *might* be used by people who like certain colors, but the primary intent is for people who need those colors<br> <stepheckles> q+<br> <TabAtkins> florian: if it happens to work for the theme enjoyers, great, but we're not designing toward them<br> <lea> q?<br> <TabAtkins> emilio: but Tab's point is, for those users it might not make a difference etierh way<br> <fantasai> TabAtkins: not necessarily. If it's subtle, might not be distinguishable<br> <ChrisL> tab++<br> <fantasai> TabAtkins: if not subtle, could defeat the contrast goals of the user<br> <astearns> ack kbabbitt<br> <Zakim> kbabbitt, you wanted to respond on the "need" vs "want" use cases<br> <fantasai> TabAtkins: if using their chosen colors, then good for them<br> <TabAtkins> kbabbitt: on need vs want, another feature is preferred color schemes, a better fit for users who just *want* dark mode or a particular set of colors but can tolerate mixes<br> <astearns> ack stepheckles<br> <TabAtkins> kbabbitt: but as others have said, forced colors is primarily about users who *need* that level of contrast<br> <TabAtkins> stepheckles: i've seen articles recently with folks becoming aware of color-scheme property, and discovering system colors as a part.<br> <TabAtkins> stepheckles: trying to get the ability to produce light/dark agnostic themes, before we have better support for light-dark()<br> <TabAtkins> stepheckles: also, the example in the GH issue didn't even use the forced-colors MQ<br> <ChrisL> Q+ to answer<br> <TabAtkins> stepheckles: so want to clarify - does color-mix() using system colors autoamtically get overriden because it's not a system color?<br> <TabAtkins> stepheckles: I think if authors have a specific reason to need a specific color to work, like color swatches for products, they still have the ability to use forced-color-adjust<br> <astearns> ack ChrisL<br> <Zakim> ChrisL, you wanted to answer<br> <TabAtkins> ChrisL: slightly confused about what was asking<br> <TabAtkins> ChrisL: system colors work the same way as normal colors<br> <TabAtkins> ChrisL: but specifcially *when* we're in forced colors mode, there's this overriding<br> <TabAtkins> stepheckles: the first examples in the issue just describe some examples without forced-colors MQ in use, so it's a little confusing<br> <TabAtkins> ChrisL: I linked to a codepen, when we're not in forced colors it seems like all browsers are happy to use system colors, mix them, etc<br> <TabAtkins> astearns: so i think i'm hearing we should resolve on no change to the spec, and consider firefox's forced-colors behavior to be a bug<br> <TabAtkins> astearns: emilio, do you want to go back to the people with this request and ahve a convo?<br> <TabAtkins> emilio: i could. I think this isn't the right decision, but I don't want to object.<br> <TabAtkins> emilio: if you have a disabled button, being able to make semi-transparent button text...<br> <TabAtkins> emilio: we don't ahve a great set of system colors to reflect the relevant state. this gives you the escape hatch to modify system colors for that<br> <TabAtkins> emilio: I think in the ideal world we'd have systme colors for all the states authors care about<br> <ChrisL> q+ to say some reasonable examples work, but allowing it also allows many unreasonable examples too<br> <TabAtkins> (making the text low contrast for disabled buttons is, very specifically, the behavior we want to avoid for forced-colors users, fwiw)<br> <astearns> ack ChrisL<br> <Zakim> ChrisL, you wanted to say some reasonable examples work, but allowing it also allows many unreasonable examples too<br> <TabAtkins> ChrisL: we've seen some good example of only changing opacity, probably benign. but if we allow color-mix to be used in general, people can do all kinds of wacky stuff, people can defeat th epoint of the mode. so i'm comfortable with it being overridden.<br> <TabAtkins> emilio: but authors could just use forced-color-adjust:none, right?<br> <TabAtkins> astearns: counter is thats' the authors specifically *choosing* to override forced colors mode. Allowing color-mix() to work allows them to screw up colors by accident.<br> <TabAtkins> emilio: i think overall they could do more good than harm, but i'm not objectin.<br> <TabAtkins> astearns: anyone else who'd object to resolving this no change?<br> <TabAtkins> RESOLVED: Close no change.<br> <TabAtkins> emilio: I guess by extension we should disallow relative colors?<br> <TabAtkins> ChrisL: yes, i'll open a separate issue due to time<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11097#issuecomment-2489223857 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 November 2024 17:54:54 UTC