- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Sep 2023 23:44:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-color-6] `contrast-color()` MVP in Level 5``, and agreed to the following: * `RESOLVED: function returns dark/light by default and the 'max' keyword for black/white` <details><summary>The full IRC log of that discussion</summary> <dael> lea: Last week we decided we do want to add to spec contract-color for most common use cae. Getting a suitable text color for arbitrary bg color. Question is should UA return only white/black and make their own algo. Or return color is up to UA and the UA returns something guar. to be readable<br> <florian> q+<br> <TabAtkins> i can represent Nicole/Chrome on this issue<br> <dael> lea: Argument from Nicole is that leaves more room to UAs for innovation. Sometimes max contrast is not as readable for everyone. Some people tend to prefer lower contrast<br> <dael> lea: Argument for black/white it's more predictable so authors can use more reliably. Also it guar. it's more likely to be readable. Also b/c it's either black or white authros can add shadow, etc. as an ingredient to do what they want<br> <dael> lea: More versatile, more predictable.<br> <TabAtkins> Q+<br> <TabAtkins> Yup I do<br> <dael> lea: We started expressing opinions last time but ran out of time. And TabAtkins requested an extra week to discuss in Google<br> <florian> q- later<br> <TabAtkins> *they<br> <dael> Rossen_: fantasai, anything you want to add?<br> <dael> fantasai: I'm pretty closely matched to lea<br> <Rossen_> ack TabAtkins<br> <dael> TabAtkins: We had a discussion. Me, Nicole, some of the canvas impl. New proposal which is essentially the preference from lea but with a bit of flexibility. You give an impot, get an output that's very light or very dark. Within some delta-e distance of white/black. Something that allows a little bit of play but still very close.<br> <dael> TabAtkins: Also with a keyword switch, prop 'max', that locks you into black or white so you can get predictable output<br> <dael> TabAtkins: I think this maintains the nice benefits of pure black/white but also allows some additional quality for browsers without distinct differences we were worried about<br> <dael> TabAtkins: I think this should still be okay. And can allow just black/white if impl want simple<br> <Rossen_> ack florian<br> <lea> q+ to say I like the new proposal, especially since authors can still get black/white with the max keyword<br> <dael> florian: I'm glad I let TabAtkins go first. Was in favor of just black/white. A little concerned if there's something smarter people will use it in interesting ways and someone will have to reverse engineer to match. But maybe if you limit the delta it won't happen too much<br> <lea> though it should be <color><br> <lea> * though it should be <color> || max? I think<br> <Rossen_> ack lea<br> <Zakim> lea, you wanted to say I like the new proposal, especially since authors can still get black/white with the max keyword<br> <dael> florian: Perhaps reverse risk where some browsers aren't smart and people don't think to engineer for the slightly different. Not entirely sure it's worth it, but you seem to think it would be<br> <TabAtkins> not too stressed on the ordering, i think our previous grammars did put the <color> first to make things slightly more consistent/parseable<br> <TabAtkins> `<color> && max?`<br> <dael> lea: I like new proposal. authors can get balck/white with max keywork, but if they want something just looking nice they can get that. I think it should be possible to put values in either order.<br> <dael> Rossen_: [reads TabAtkins IRC]<br> <dael> Rossen_: Seems like new proposal from TabAtkins is winning solution here. Other opinions?<br> <lea> q?<br> <astearns> I am skeptical there are quality-of-implementation tweaks that will make this switch worth it (I expect you would need to know *what* the color will be used for to make effective tweaks). But I will not object.<br> <dael> TabAtkins: I propose lea and chris tell us the reasonable variation<br> <florian> s/people don't think to engineer for the slightly different/authors don't bother specifying max before applying effects, and then the browser(s) that were trying to be smart might need to revert to pure black and pure white, but then we're not worse off than where we started/<br> <lea> q+ one concern, from my designer days: It's much more common to want white text on a bright color, and a darker version of the background color instead of black. Right now you can either get black/white or dark/light, but not dark/white<br> <lea> q+<br> <dael> fantasai: Authors typically particular about hue and less about brightness. If you end up with navy blue text on white would author be happy? If Chrome gives navy blue but Safari gives dark maroon and FF does charcol gray, I feel like authors will be unhappy<br> <fantasai> s/white/cream/<br> <dael> TabAtkins: Our hope is distance from black and white is small enough that you can't have enough variation to clash on the page. And if they are unhappy you can say max.<br> <dael> fantasai: They may not be unhappy b/c looks good where they test<br> <dael> TabAtkins: Our hope is with the maximum divergence all results should be generally acceptable<br> <dael> fantasai: Let's say gray. People are sensitive to warm or cool. If some UA pick warm and some cool people will have sensitivity to what. What's benefit to allow gray be warmer or cooler? How far off can you be to get a benefit and no problem?<br> <dael> TabAtkins: Point is we want to experiment. We think this ability is valuable. There's a lot of work in experimentation and theory to figure out what's best. The hope is we eventually can write an algo. Hope is give authros something predictable for now that lets us play around to find the right spec<br> <Rossen_> q<br> <dael> fantasai: And you're arguing this should be default? We should create this difference in hue b/c that's a better default?<br> <lea> +q another issue is that if one browser returns black/white and another dark/light, this is practically unusable (without max)<br> <dael> TabAtkins: Yes. We believe the little bit of exporation will be acceptable as a default even if it's slightly different across browsers<br> <dael> lea: At first I quite liked proposal, but thinking more one issue is that if one browser gives always black/white and other does dark/light then the authors that want dark/light can't do anything with the values<br> <Rossen_> ack lea<br> <dael> lea: Even with relative color trying to think what math to use get light or dark on browsers that do black/white. I can do it with alwyas blakc/white<br> <dael> lea: Also, remember in graphic design more common to want white text on a bright color bg. If the color is so light it needs dark text it's more common to want not black. Current proposal doesn't let you distinguish and mix and max<br> <dael> TabAtkins: White is a valid light color<br> <dael> florian: But author can't ask for it<br> <dael> lea: What I'm saying is I want white if it would work and a dark color instead of black. Can't spec that intent i don't know if that's as wide spead as I remember. No way to spec that<br> <dael> TabAtkins: That can't be done in any syntax we discussed except listing explicit colors. Unless browser is smart enough to know<br> <dael> lea: If it returns white and black you can use max<br> <Rossen_> q?<br> <dael> florian: If as an author you want to manipulat eyou put in 'max'. If you want to tweak ask for the predictable thing<br> <dael> florian: I'm skeptable that the distance from white/black is small enough to be useful but not so large it can be bad<br> <lea> what I was referring to: lch(from var(--color) clamp(.2, l, 1) c h)<br> <astearns> +1 to florian's last point<br> <dael> TabAtkins: We're hoping it's not. Remember the falure case if we're wrong is we change the default to black/white<br> <fantasai> +1 to florian's point<br> <dael> Rossen_: I'd like to start getting to a resolution if we can<br> <Rossen_> ack fantasai<br> <florian> q+<br> <dael> fantasai: I have concerns about interop and suitability of automatic algo. I don't think it should be default, but I understand chrome has ideas to experiement. I don't think experiment is harmful if not shipping. I would prefer to spec black/white, add a note we're experiementing with other values, and let chrome experiment as a prototype<br> <lea> q?<br> <lea> q+<br> <dael> fantasai: If they get buy-in from dev community that they want the new behavior we can move. I don't think I'd want to spec UA magic at this point<br> <dael> TabAtkins: Issue with current channels is it's by definition people clued into the topic. if people are clued in they can do color manipulation on their own. We believe there is play to offer the general dev audience and there's not room in the channels we have for that<br> <Rossen_> ack florian<br> <dael> florian: One of the downside of fantasai's comment is Chrome wants a signal from authors that will mess with colors that they're going to do that. If we do the way fantasai suggested we don't have that signal. But you can maybe look for authors doing more with it<br> <dael> lea: I think what fantasai desc makes sense. Worried about interop when leaving to UA. If chrome experiments and gets results authors like we can add additional behavior for it.<br> <dael> lea: and/or we can introduce additional assurances to make sure result is predictable. Has to maintain same hue or something, but reduces innovation. I don't know what experiements they have in mind<br> <dael> TabAtkins: We don't know yet either. we'll play to see what gets good results<br> <Rossen_> q?<br> <Rossen_> ack lea<br> <dael> lea: Why not ship the simple version now, experiement, and add the new one later<br> <dael> TabAtkins: If it is something else it's by definition not going to be the first thing people reach for when they don't know what they want. The hop here is we can make the default good for people who just want a good text color. People who know color theory and want to play should be able to do that.<br> <Rossen_> q?<br> <dael> TabAtkins: The goal here precludes a switch for later. If this will be worthwhile it needs to be a default<br> <dael> Rossen_: And TabAtkins what you're saying is the additive behavior...what's the difficulty there? If we resolve on black/white now and add the 'max' keyword to do more?<br> <schenney> q+<br> <dael> TabAtkins: The 'mx' keyword forces you into black and white. All other values will be slightly-less contrastly. Also, it's that if you don't know how colors work, which most people don't, you're not going to reach for an optional keyword?<br> <dael> lea: Doesn't that depend on name?<br> <dael> TabAtkins: All optional keywords are treated as less default<br> <dael> fantasai: I see TabAtkins's point<br> <Rossen_> ack schenney<br> <dael> schenney: florian made an excellent point. If you wish to experiment having the default be to play and the max keyword it makes it rediculously easier to experiment. You get good signal. If you only have black/white it's very hard to infer what people want. For that reason the proposal from TabAtkins is best for a long term answer<br> <lea> TabAtkins: yes, optional keywords are used less often; but my point was that whether authors that don't know about color theory reach for the keyword depends on the keyword name. Like, the keyword doesn't need to be worded in such a way that it depends on color theory<br> <dael> florian: I'm not too hot for the proposal, but there is a chance it's useful and low risk if we define the distance short enough. If it's too far we'll get feedback and maybe we end on black/white<br> <TabAtkins> yeah we're thinking that, like, an #eee or an #eef rather than a pure #fff, very short distance<br> <dael> Rossen_: Let's see if we can resolve on TabAtkins's proposal. Other comments?<br> <dael> fantasai: It may be nice to start with mroe restricted audience trials to see if you get answers in those environments first.<br> <dael> Rossen_: how does that change the proposal?<br> <dael> fantasai: I think I would feel more postivie about it if there were positive signals in a restricted community<br> <dael> TabAtkins: We know for a fact that very often people reach for slightly off-white and off-black. That's from color design bible. Do #111 or #eee. That suggests we should be slightly off white/black for this. but it doesn't tell us exact value<br> <lea> q+<br> <dael> florian: Black and white are valid answers to if experiment isn't conclusive we can ship black/white<br> <Rossen_> ack *<br> <Rossen_> ack lea<br> <fantasai> those are both neutral grays...<br> <fantasai> but ok<br> <dael> lea: What TabAtkins is saying is true. It is common designers use off-white instead of white. Text size, font, weight, etc...the CSS function can't know it's context<br> <dael> TabAtkins: A lot of these factors could be inferred<br> <dael> lea: Are you suggesting we spec a color fucntion that's different based on what property it's in? That's not how color functions work<br> <dael> TabAtkins: I'm saying it could and we'll figure out to what extent we may want them to differ<br> <dael> Rossen_: We've talked for 30 minutes and I think we're starting to circle. We can try and resolve or go back to the issue to discuss more since this is a newer proposal.<br> <dael> TabAtkins: The exact proposal is new, but we have been discussing this area since NY F2F<br> <dael> lea: Agree. What about a straw poll<br> <dael> Rossen_: What are the options?<br> <dael> lea: 1. function returns black/white by default<br> <astearns> Returning a single non-b/w color based on the input color is one thing. Returning several different colors from one input color based on where the function is used is VERY different. You should make that explicit in the proposal if that is the case.<br> <dael> lea: 2. function returns dark/light be default and the 'max' keyword for black/white<br> <dael> s/be/by<br> <fantasai> 0, defer to jensimmons who unfortunately isn't here...<br> <TabAtkins> When the output space is wide, the difference matters more. When the output space is a small radius aroudn black/white, we believe it's probably fine.<br> <schenney> 2<br> <TabAtkins> 2<br> <florian> 2 (not a very strong opinion)<br> <iank_> 2<br> <astearns> 1<br> <lea> 1<br> <fantasai> Also! IIRC we'd resolved to require the "this is for text" vs "this is for background" keywords, is that being handled?<br> <smfr_> 2<br> <changseok> 1<br> <vmpstr> 2<br> <lea> fantasai: not for the MVP<br> <Rossen_> 2<br> <dholbert> abstain (no strong preference)<br> <emeyer> Abstain<br> <fantasai> lea, so which are we assuming? text or background?<br> <lea> fantasai: provided color is bg<br> <TabAtkins> input is background, output is text<br> <dael> Rossen_: We've got a clear signal for option 2<br> <dael> Rossen_: One of the things I didn't hear during discussion since this is a11y related- by returning black/white we are forcing more often higher contrast than user may prefer. Option 2 addresses this well.<br> <dael> Rossen_: Objections to function returns dark/light by default and the 'max' keyword for black/white<br> <dael> RESOLVED: function returns dark/light by default and the 'max' keyword for black/white<br> <dael> [agenda wrangling]<br> <dael> [waiting for Chris on #8543]<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9166#issuecomment-1709264221 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 September 2023 23:44:27 UTC