- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jan 2025 21:48:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `` `contrast-color()` MVP should support explicit light/dark colors rather than unspecified "very light/dark colors"``, and agreed to the following: * ``RESOLVED: drop `max`, do white/black by default and allow extension points later`` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> lea: a while back we resolved to adopt an MVP for contrast-color<br> <hober> q+<br> <kbabbitt> ...that returned very light and very dark color, up to UA what they would be<br> <kbabbitt> ... and max version that returned white and black<br> <kbabbitt> .. after working with designers more, I've seen they don't want arbtirary dark or light color<br> <kbabbitt> ... they want specific tokens<br> <kbabbitt> ... use this dark text color, not some arbitrary decided by browser coor<br> <kbabbitt> ... in theory they could use max, get white and black, and transform it<br> <kbabbitt> ... but it seems like an easy win if you could specify your light and dark versions<br> <kbabbitt> ... ideally start with just providing dark one<br> <kbabbitt> ... usually white is OK as text color but black isn't<br> <kbabbitt> ... if you provide colors you can end up in situations with insufficient contrast<br> <kbabbitt> ... but you can do that already<br> <kbabbitt> ... so that doesn't make things worse<br> <kbabbitt> ... it's in Safari but not implemented widely<br> <kbabbitt> ... I would suggest a syntax that takes args for light and dark color, drop max, and if you don't provide args you get max behavior<br> <kbabbitt> ... 1 arg is dark color with white as light color<br> <kbabbitt> ... 2 args use those<br> <kbabbitt> ... maybe UA can figure out which is which<br> <kbabbitt> ... or we can be ordered<br> <kbabbitt> ... pretty small syntax extension<br> <kbabbitt> hober: really interesting problem, we had ? to talk through it internally<br> <kbabbitt> ... it's intersting because it turns out contrast-color is something lots of people want<br> <kbabbitt> ... for different reasons with different constraints<br> <kbabbitt> ... after we whiteboarded it, we felt best way would be separate CSS functions for different use cases<br> <kbabbitt> ... filed a new issue to suggest that<br> <kbabbitt> ... space of desired behaviors & why we think they should be separate functions<br> <kbabbitt> ... 2 proposals we kicked around<br> <kbabbitt> ... one is maintainer of small/medium website who realizes that previous designer didn't use sufficient contrast<br> <astearns> https://github.com/w3c/csswg-drafts/issues/11619<br> <kbabbitt> ... trying to bring website into modern world but don't have time to redesign it<br> <kbabbitt> ... make smallest change they can that gives sufficient contrast<br> <kbabbitt> ... other is designer at a company with well thought out brainding identity<br> <kbabbitt> ...who really needs colors from a specific set<br> <kbabbitt> ... use cases all over the place<br> <kbabbitt> ... given this color, compute a contrasting color<br> <kbabbitt> ... but ambiguous because color could be used for foreground, background, borders, etc.<br> <kbabbitt> ... that's teh case we want contrast-color for<br> <kbabbitt> .. other case, given a starting color and set of colors<br> <kbabbitt> ... get the color from the set that contrasts most<br> <kbabbitt> ... guaranteed color you get out is one of the ones you put in<br> <kbabbitt> ... this also has variations because you might have different thresholds for borders etc<br> <kbabbitt> ... then there's a case where you have a pair of colors for fg and bg<br> <lea> q?<br> <lea> q+<br> <kbabbitt> ... ask engine, make minimum tweaks to these<br> <kbabbitt> ... one other that james craig though tof, put text on bg image<br> <kbabbitt> ... who knows colors of bg image, but you want a color that contrasts sufficiently<br> <TabAtkins> lea's proposal is more limited than "here's a list, pick the best" - instead you first determine whether white or black would be better, then let authors supply a replacement for white/balck<br> <kbabbitt> ... all of these are interesting and probably need different functions<br> <kbabbitt> ... disinclined to make color-contrast more complicated to do all these things<br> <TabAtkins> q+<br> <kbabbitt> ... but do want to do all of these things<br> <kbabbitt> ... using separate functions<br> <astearns> ack lea<br> <hober> https://github.com/w3c/csswg-drafts/issues/11619<br> <astearns> ack hober<br> <kbabbitt> lea: when we resolved to do contrast-color it was because there was all this complex design space & use cases<br> <kbabbitt> ... no good algorithm we could use right now<br> <kbabbitt> ... [gives examples]<br> <kbabbitt> ... so we resolved to leave it up to UA<br> <kbabbitt> ... address most common case which is light + dark color<br> <argyle> 17 use cases outline in my proposal from a couple years ago https://observablehq.com/@argyleink/contrast-color, sharing here to be added to the considerations<br> <kbabbitt> ... these use cases exist but a lot of this is going back to debates where we got gridlock because it was such a big problem we couldn't move forwards<br> <kbabbitt> ....we resolved to have this version because it addresses 80% of use cases without complexity<br> <kbabbitt> ... looking to keep that<br> <kbabbitt> ... maybe we'll solve others with same fn, maybe with different fns<br> <kbabbitt> ... it's a matter of syntax<br> <kbabbitt> ... poit of this proposal is to solve common case<br> <florian> q+<br> <kbabbitt> ... don't think others are something we need to solve right now<br> <kbabbitt> ... proposing a simple tweak over what we have right now<br> <kbabbitt> ... supplying optional replacements for white & black<br> <argyle> q+<br> <kbabbitt> ... it's not responsible for maintaining contrast ratios for you<br> <kbabbitt> ... if previous proposal could be implemented easily this could be too<br> <kbabbitt> ... hober's points are valid but lots of design work involved<br> <astearns> ack TabAtkins<br> <kbabbitt> TabAtkins: agree with lea<br> <kbabbitt> ... trying to avoid reopening big design discussions<br> <kbabbitt> ... this is a minimal edit to what WG decided on<br> <kbabbitt> ... to address lea's concerns without opening new problesm<br> <kbabbitt> ... I think we should accept this change, bikeshed syntax later<br> <astearns> ack florian<br> <kbabbitt> florian: worried this is a footgun<br> <kbabbitt> ... yes if the color you get is actual black or white<br> <kbabbitt> ... even if contrast function isn't perfect it will be good enough<br> <lea> q?<br> <kbabbitt> ...but here you allow user to supply something else<br> <lea> q+<br> <kbabbitt> ... sometimes they'll be surprised what's picked because contrast won't be good<br> <kbabbitt> ... sometimes what we have makes bad decisions but you know it's black or white<br> <hober> qq+ to riff on florian's footgun<br> <kbabbitt> ... if you're almost entirely black maybe not but depending on how far off you are, sometimes it will give you the wrong one between the two<br> <astearns> ack hober<br> <Zakim> hober, you wanted to react to florian to riff on florian's footgun<br> <kbabbitt> hober: thats exactly my worry<br> <kbabbitt> ... if we had a separate fn that solved, given set of colors give me one that contrasts<br> <kbabbitt> ... that would be a simple change of syntax that would address that<br> <TabAtkins> q+ to respond to tess<br> <kbabbitt> ... while it's still a footgun, if you always have one color and it returns that regardless of contrast<br> <kbabbitt> ... that's less of one because you're providing a set of colors<br> <kbabbitt> ... this is areduced version of that where you're only providing 1 or 2<br> <kbabbitt> ... this is a guess because all we have to go on is intuition<br> <florian> q?<br> <kbabbitt> ... but I think authors are less likely to screw up in that case<br> <kbabbitt> ... this isn't as good as a separte function but think we should try to solve the problem<br> <astearns> ack argyle<br> <kbabbitt> argyle: lea mentioned... I don't know any designers okay with partial color choice that didn't come from their palette<br> <kbabbitt> ... most people I've talked to is the opposite<br> <kbabbitt> ... they open palette and lcick around the pool<br> <kbabbitt> ... if you have a set and want to pick from it, good feature, but not all designers explicitly want it<br> <kbabbitt> ... we leave tasks up to browser a lot, sometimes it's not the right answer<br> <kbabbitt> .... contrast prefs of user should be taken into account<br> <kbabbitt> ... in high contrast mode this fn should return something relevant<br> <kbabbitt> ... I've tried all algos, we should punt on forcing one<br> <kbabbitt> ... we shouldn't be waiting for better algo<br> <kbabbitt> ... enhancing what we have is good, white black or from a list<br> <florian> q+<br> <kbabbitt> .... bad contrast is one of biggest a11y problems on web<br> <astearns> ack lea<br> <kbabbitt> lea: agree with argyle on taking HC into account<br> <kbabbitt> ... re: footgun - I think people are comparing to ideal fn which we don't know how tyo build<br> <weinig> q+<br> <kbabbitt> ... but without this, designers are specifying these manually<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <kbabbitt> ... we can be absolved of responsibility, they picked it<br> <kbabbitt> ... re: having UA pick, there's not enough info in a tint to give you other tints of that color<br> <kbabbitt> ... varying lightness is not sufficient in any color space<br> <kbabbitt> ... even oklch<br> <kbabbitt> ... still have to vary chroma to get tints<br> <kbabbitt> ... if starting from a light color you can't derive darker variants<br> <kbabbitt> ...without having accent color<br> <kbabbitt> ...missing information<br> <nicole> q+<br> <kbabbitt> ...I don't think UA can come up with a good color<br> <kbabbitt> ...not a terrible result to get black & white if nothing provided<br> <kbabbitt> ... I think for the people picking madly around a color picker, they can deal with black & white<br> <kbabbitt> ... I don't think UA generating dark color would help them very much<br> <astearns> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to respond to tess<br> <fantasai> scribe+<br> <fantasai> TabAtkins: Responding to Tess, the big thing that blocked us last time was the idea of having a function that could pick from a list of colors *because* we know our current contrast algo sucks<br> <kbabbitt> TabAtkins: our existing algo sucked and we didn't have a good replacement<br> <kbabbitt> ... that's why we subsetted down to 2 color case<br> <kbabbitt> ... white and black can go a little wrong but hard to go very wrong<br> <kbabbitt> ... going back on that will reopen every problem we had before deadlock was resolved<br> <kbabbitt> ...it is possible to footgun by supplying dark color instead of black<br> <kbabbitt> ... don't do that, we'll tell them not to do it in spec<br> <argyle> just sharing this again, as this lets you see returned colors from any contrast algo, from a list, or max white/black OR it can discover a color. all of these options we're sharing here are in this demo, and you can see how totally decent the results are https://observablehq.com/@argyleink/contrast-color<br> <kbabbitt> ... can supply own colors, they should be very dark very light<br> <kbabbitt> ... still gets us to a defensible spot even if we're stuck with ? as contrast algo<br> <kbabbitt> s/?/WCAG2/<br> <astearns> ack florian<br> <kbabbitt> florian: building on TabAtkins and lea were saying<br> <kbabbitt> ...thinkinh of it as a footgun compared to doing it manually<br> <kbabbitt> ... problem case is a light on dark theme where dark isn't very dark<br> <kbabbitt> ... and you ask for contrast between middle color and give me black or white<br> <kbabbitt> ... and get kind of gray<br> <kbabbitt> ... to contrast on kind of gray<br> <kbabbitt> ... and this fn which is supposed to give you good contrast, doesn't<br> <kbabbitt> ... on one hand, don't do this, on the other hand this is the fn that ghives me contrasty<br> <kbabbitt> ... so the only thing I can put in there is gray<br> <kbabbitt> lea: isn't that a problem with current version?<br> <kbabbitt> florian: no because it returns black<br> <kbabbitt> ... it won't return middle gray<br> <kbabbitt> ... if you can't use black, you won't use function<br> <kbabbitt> ... you won't supply it middle gray, you won't use it at all<br> <astearns> ack weinig<br> <fantasai> +1<br> <kbabbitt> weinig: second time I've impled this function, shipped it behind a flag<br> <TabAtkins> as lea pointed out earlier, you can *turn* white/black into chosen colors via RCS, fwiw<br> <fantasai> that's more explicit though. The author won't think they're getting an actual contrast computation<br> <kbabbitt> ... how do we get to the point where this is good enough and get user feedbacl?<br> <kbabbitt> ... can we resolve on this version and try it out, see feedback<br> <lea> If we can't reach consensus on this, I wonder if we can just drop `max` (and do white/black by default) so that we can extend the function later with something like this<br> <fantasai> +1 lea<br> <kbabbitt> ... seems unnecessary to keep iterating if it's contentious<br> <kbabbitt> astearns: not hearing consensus for any particular resolution<br> <kbabbitt> ... let's take back to issue<br> <kbabbitt> ... we may decide to extend as lea suggests<br> <kbabbitt> ... might need different version<br> <miriam> +1<br> <lea> (fwiw I think that's a better design *anyway*)<br> <TabAtkins> i'm fine with that<br> <kbabbitt> Proposed: drop `max`, do white/black by default and allow extension points later<br> <kizu> +1<br> <fantasai> +1<br> <lea> 🎉<br> <kbabbitt> RESOLVED: drop `max`, do white/black by default and allow extension points later<br> <argyle> +1 that's how my proposal works in that observable<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11534#issuecomment-2625667244 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 January 2025 21:48:18 UTC