- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Feb 2023 18:03:02 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-6] Let's finally settle contrast-color() syntax`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> lea: The primary problem we couldn't settle on was what to call foreground/background. We reoslved to distinguish them in the syntax but couldn't decide on names<br> <TabAtkins> lea: foreground/background too long, fg/bg too cryptic, others suggested front/back, fore/back<br> <TabAtkins> lea: There's a table of the options<br> <TabAtkins> lea: And should we have a default if the keyword isn't specified? Probably with bg as the base color, which'll be the most common case? Or should we require the keyword?<br> <TabAtkins> fantasai: I think I'm strongly in favor of it being mandatory, so people will pay attention<br> <TabAtkins> lea: advantage of making it options is that only the fg word actually matters so we can just pick a good name there. can also be longer since it's not typed as much<br> <TabAtkins> argyle: That's my proposal - make it optional and make the fg keyword short and easy.<br> <argyle> https://observablehq.com/@argyleink/contrast-color<br> <TabAtkins> argyle: This is the interactive explianer, syntax is right under the demo<br> <argyle> https://www.irccloud.com/pastebin/mO4ENSCC/<br> <lea> s/and make the fg keyword short and easy./and have the whole foreground keyword, since it's the exception/<br> <TabAtkins> [gonna have argyleink present]<br> <TabAtkins> Rossen_: If you need to present visually, our next zoom meeting will be next month<br> <TabAtkins> [more presentation chatter]<br> <TabAtkins> argyle: Bunch of examples in this observable document later<br> <TabAtkins> argyle: The current spec isn't far off from excellent, i think, so my important bits in myc ounter proposal:<br> <TabAtkins> argyle: First, doesn't require a color list<br> <TabAtkins> argyle: Lot of presenting to devs and using it myself, i often dont' care about the final color<br> <TabAtkins> argyle: It'll find the first color that passes for you, in the same hue, in whatever contrast algo you're using<br> <TabAtkins> argyle: Further my proposal builds in the contrast MQ pref<br> <TabAtkins> argyle: So if the user prefers more contrast and the page is rendered without a color list, or an explicit contrast pref in the function, the browser will take the user's preference by default.<br> <TabAtkins> argyle: This potentially eliminates several MQs for authors to have to worry about<br> <TabAtkins> argyle: If an author *does* write a specific target score - "Weber 2" or whatever - they're actually potentially excluding users.<br> <TabAtkins> argyle: So if someone does want to handhold the contrast today, they have to write several MQs to set things correctly in several circumstances. My proposal folds it all in by default.<br> <TabAtkins> argyle: Color list is still important, if you *do* want it, but you don't need it a lot of the time.<br> <TabAtkins> argyle: As said earlier, it defaults to "background". You can click it to foreground and see it change the syntax to include the keyword.<br> <TabAtkins> argyle: In most caess I've done I'm starting from a background, it's just the most common.<br> <TabAtkins> argyle: Also have a "max" contrast target<br> <astearns> "color: contrast-color(#eee / max);"<br> <TabAtkins> argyle: If I just pass a starting color it'll get the max-contrast color (white or black)<br> <lea> q?<br> <TabAtkins> argyle: There's also options matching the contrast MQ - "more" or "less"<br> <TabAtkins> argyle: Without having to specify exactly a contrast algo.<br> <TabAtkins> argyle: The contrast algo is auto by default, i know that's controversial<br> <argyle> https://codepen.io/argyleink/pen/RwgzJXV<br> <TabAtkins> argyle: Here's a demo<br> <TabAtkins> argyle: I'm writing a codepen with light/dark and low/medium/high contrast<br> <TabAtkins> argyle: You should be immediately overwhelmed<br> <TabAtkins> argyle: Just a lot to write<br> <argyle> https://codepen.io/argyleink/pen/eYKmMmN<br> <TabAtkins> argyle: This demo is what I've seen people instead already do<br> <TabAtkins> argyle: Hand-managing oklch deltas in each MQ. Slightly automated, better than WCAG 2 but not perfect. But it works today and gets light/dark and low/medium/high contrasts<br> <TabAtkins> argyle: My proposal today would make both of those demos a one-liner.<br> <TabAtkins> argyle: Looks at user pref and auto-discovers what colors they should get<br> <argyle> contrast-color(Canvas)<br> <TabAtkins> argyle: This one-liner gives you light/dark and low/med/high contrast<br> <lea> q+<br> <TabAtkins> argyle: Current proposal requires authors to write a longer function, and repeat it several times.<br> <TabAtkins> argyle: so "auto" as the algo complements the author's desire for not having to make a choice. browser can just do what's bet.<br> <TabAtkins> argyle: If there's no auto target there's no way to give up choice<br> <TabAtkins> argyle: So to summarize, my proposal doesn't require a color list, defaults to background, offers less/more/max contrast keywords, has an auto contrast keyword<br> <TabAtkins> argyle: It starts simple, *can* do everything currently in the spec, but doesn't require all the complexity immediately.<br> <Rossen_> ack lea<br> <TabAtkins> lea: We all like sensible defaults, but there were several issues with default algorithm that were discussed ad nauseum<br> <TabAtkins> lea: WCAG 2.0, the current default, is just bad. There are better algos, but there are patent/licensing issues<br> <TabAtkins> lea: In our experiments in Color.js the other contrast algos listed in the proposal don't actually give good results either<br> <TabAtkins> lea: So I don't think they're needed<br> <TabAtkins> lea: I like the idea of integrating this with the preferred contrast MQ<br> <TabAtkins> lea: Unclear what it does exactly - same keywords, or does the MQ value actually affect the function?<br> <TabAtkins> lea: minor comment - i find the identifiers side-by-side kinda hard to read, like "abca max"<br> <TabAtkins> lea: Nothing making it clear that they're tied together - current syntax makes the algos functions so you're sure the args are realted<br> <TabAtkins> lea: Also not sure what "more"/"less" correspond to mechanically<br> <TabAtkins> lea: I do like the idea of having background be the default<br> <TabAtkins> lea: Not sure we need "backgroudn" keyword at all then<br> <TabAtkins> argyle: yeah, wcag2 is bad, apca3 is still not producing good results yet, still a few years out<br> <TabAtkins> argyle: If we wait for optimal it'll never ship<br> <TabAtkins> argyle: I think auto sets it up to grow and for users, if they have a pref, they can specify it<br> <TabAtkins> argyle: I think most people won't even look past wcag2 being bad<br> <lea> q+ to say several members were skeptical about having an auto algorithm that could change. Worries we'll be stuck with it forever because authors will depend on the results not changing<br> <TabAtkins> argyle: so it's hard for us<br> <TabAtkins> argyle: Say apca comes out and is stable, firefox flips to taht, it woudl b eneat to see it upgrade over time<br> <TabAtkins> argyle: I just don't like baking in a bad choice<br> <TabAtkins> argyle: I also agree nobody really knows about the other algos, yeah<br> <TabAtkins> argyle: So MQ syntax, what is more/less? I had to invent this in my demo - what is more/less in each algo?<br> <TabAtkins> argyle: I have a table in my proposal mapping them to particular values in each algo.<br> <lea> Btw our experiments with these other algos (for black/white only): https://colorjs.io/apps/blackwhite/<br> <TabAtkins> argyle: we'll have to figure this out anyway, for the MQ<br> <TabAtkins> +1 to the simple keywords that correspond to *some* reasonable values for the algos, I really like that<br> <argyle> contrast-color(#eee / max apca)<br> <TabAtkins> argyle: You commented that this looks a little weird<br> <TabAtkins> argyle: I think this reads really nice personally<br> <TabAtkins> argyle: I want max contrast from apca<br> <lea> q+ just remembered, there's also the issue of allowing multiple algos (e.g. a good one + wcag for legal requirements), this syntax cannot grow to accommodate that since params and algos are on the same level<br> <TabAtkins> argyle: If you do change the algo to something else, you're saying "here's my bg color, here's the target score"<br> <TabAtkins> argyle: --and hopefully you alway suse auto, anything else can exclude users with particular prefs--<br> <Rossen_> q?<br> <lea> I also like "more" or "less"<br> <TabAtkins> lea: I wrote in IRC what i was gonna say<br> <TabAtkins> lea: In prev discussions several WG members wer eskeptical about an auto algorithm that can change<br> <TabAtkins> lea: We'll freeze in practice anyway<br> <TabAtkins> lea: The other issue is that we might want to allow multiple algos that all need to pass - specify a "good" algo but also a "legally required" algo. Current syntax doesn't accommodate this, since the algo specifiers are on the same level as the algo name itself<br> <argyle> contrast-color(#eee / 60 lstar)<br> <TabAtkins> lea: I do like the more/less keywords fwiw<br> <lea> q?<br> <TabAtkins> argyle: You're right, I can't do multiple algos right now - "60 lstar, and 4 wcag"<br> <Rossen_> ack lea<br> <Zakim> lea, you wanted to say several members were skeptical about having an auto algorithm that could change. Worries we'll be stuck with it forever because authors will depend on the<br> <Zakim> ... results not changing<br> <lea> contrast-color(#eee / 60 lstar 5.4 wcag2) makes no sense<br> <TabAtkins> fantasai: I think this exploration was v helpful<br> <TabAtkins> fantasai: I do think there are problems with the proposal<br> <lea> +1 to this exploration being v helpful!<br> <TabAtkins> fantasai: Really do need to keep the target amount a functional argument<br> <TabAtkins> fantasai: Both good for reading and for parsing<br> <TabAtkins> fantasai: functional notation lets us extend the new algos with whatever we need without ambiguity<br> <argyle> functional notation is an easy change<br> <TabAtkins> fantasai: i have concerns about auto picking colors to minimum acceptable contrast<br> <lea> (note that functional notation can also have an argument-less syntax, where we omit the ())<br> <TabAtkins> fantasai: "pick the right contrast" is usually not the minimum acceptable<br> <TabAtkins> (we can also have some simple args to the "default" algo not require mentioning the algo)<br> <TabAtkins> [whoops, missed]<br> <TabAtkins> fantasai: if we do color ranges, should probably have ability to do ranges of any color, not just the bg hue<br> <TabAtkins> fantasai: maybe default it to the bg hue<br> <TabAtkins> fantasai: BAck to syntax, you're having a color, then a slash, then a list of colors<br> <TabAtkins> fantasai: some disagreement in earlier proposals about where the algo goes, i find your syntax choice interesting and think it reads nicely<br> <TabAtkins> fantasai: wrt fg/bg i'm pretty strongly against allowing one of them to be defaulted. i do think that needs to be an explicit choice<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/7937#issuecomment-1431751840<br> <TabAtkins> fantasai: but I think we can do that without being too wordy if we put it into the function name - contrast-foreground() and contrast-background()<br> <TabAtkins> fantasai: And I think we need to tackle these problems individually<br> <TabAtkins> fantasai: auto algo? No, we already resolved that.<br> <lea> unclear if contrast-foreground(red) is declaring that red is the foreground or asking for a foreground color where red is the background<br> <TabAtkins> fantasai: function algos? etc. we can address those one by one.<br> <argyle> thx y'all, sorry that def wasnt 5m<br> <TabAtkins> Yeah I think that's confusing too<br> <lea> argyle: nothing syntax related ever is 5m :)<br> <TabAtkins> (re: Lea's comment)<br> <TabAtkins> Rossen_: We'll continue discussing in 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/7937#issuecomment-1431788247 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 February 2023 18:03:04 UTC