- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Aug 2022 15:44:22 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `specifying the contrast algo for color-contrast()`, and agreed to the following: * `RESOLVED: Allow color-contrast() to specify the algo and level, by taking an algo function as an arg` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Subtopic: specifying the contrast algo for color-contrast()<br> <TabAtkins> lea: since there are problems with every contrast algo known right now<br> <TabAtkins> lea: wcag2 is well known but with big problems<br> <TabAtkins> lea: theres' a study linked in the issue that shows it has something like 40% false results<br> <TabAtkins> lea: we suspect the reason in practice people don't realize how bad it is is because the colors you feed in aren't random, they're already "probably readable", so this is a second line of defense<br> <TabAtkins> lea: but once it's baked into a css algo it'll be used to generate color pairs without author intervention<br> <TabAtkins> lea: so if it's this bad, we can't use it<br> <TabAtkins> lea: otoh, ACAG[?] is positioned as a successor, but has issues<br> <TabAtkins> lea: Patent filed for it, unclear if it's usable<br> <TabAtkins> lea: weird note about licensing for web-based usages<br> <chris> qq+<br> <TabAtkins> lea: and the author has been rather difficult to work with, got a temp ban from w3c<br> <una> q+<br> <TabAtkins> lea: there are some other algos, chris probably knows more, they also generally don't produce great results<br> <chris> s/ACAG[?]/APCA<br> <TabAtkins> lea: So a) it should be possible to specify the algo specifically, rather than picking a default<br> <flackr> q+<br> <TabAtkins> lea: but even if we make it mandatory, that's not a solution, authors will learn an invocation and we won't bea ble to shift away<br> <TabAtkins> fantasai: So not shipping yet, but we stil lneed to add keywords<br> <TabAtkins> lea: not keywords, some kinda function since the levels are different fro each algo<br> <Rossen_> ack chris<br> <Zakim> chris, you wanted to react to lea<br> <TabAtkins> chris: re the patent situation<br> <TabAtkins> chris: At a certain maturity level you can lodge an exclusion<br> <TabAtkins> chris: In this case the patent was disclosed but not excluded<br> <TabAtkins> chris: the actual disclosure has some wording about license restrictions<br> <TabAtkins> chris: the patent policy does not allow such restrictions<br> <TabAtkins> chris: it needs RAND as well as free<br> <TabAtkins> chris: w3c patent people say it's unenforcable<br> <TabAtkins> chris: so currently it seems to be royalty-free<br> <Rossen_> q<br> <florian> q-<br> <TabAtkins> florian: the patent disclosure period has elapsed, and there was no exclusion<br> <lea> q+<br> <chris> q+ to talk about levels per algorithm<br> <TabAtkins> una: agree its 'important to speciy the algo<br> <Rossen_> ack una<br> <TabAtkins> una: Wanna be able to use new algos in the future<br> <lea> q-<br> <TabAtkins> una: Yesterday we also talked about letting the browser decide the auto algo<br> <dbaron> +1 to "should be able to specify the algorithm" (pending the details, which are in other issues!)<br> <TabAtkins> una: If wcag2 is the current default, we want the browser to be able to update to new ones<br> <TabAtkins> una: I think this can be done if there's no keyword (or auto?)<br> <TabAtkins> una: and a keyword means the user always wants a specific algo<br> <TabAtkins> una: seems like best of both worlds for usability and ability to be specific for contrast algo<br> <TabAtkins> una: tldr, should be able to specify contrast algo but also should be able to say auto<br> <Rossen_> ack florian<br> <Rossen_> ack flackr<br> <TabAtkins> flackr: if the user has told the browser they have a color deficiency, can the UA take that into account and select a contrasting color based on it?<br> <TabAtkins> chris: people with atypical color vision don't ahve reduced contrast sensitivity<br> <TabAtkins> chris: with exception of red-on-black<br> <TabAtkins> chris: where they're actually better<br> <Rossen_> q?<br> <Rossen_> ack chris<br> <Zakim> chris, you wanted to talk about levels per algorithm<br> <TabAtkins> chris: re the "function instead of keyword", it's because the different algos use different numeric ranges<br> <TabAtkins> dbaron: responding to una<br> <Rossen_> ack dbaron<br> <TabAtkins> dbaron: maybe pushing a little outside this issue<br> <TabAtkins> dbaron: i am skeptical of anything where we ship something and later change what color is produced<br> <TabAtkins> dbaron: people will evaluate whether they've succeeded in their design not just by writing a contrast(), but also by looking at it and making sure they like it<br> <florian> +1<br> <TabAtkins> dbaron: if we go and change the colors later, people will probably be unhappy and pages will be broken<br> <TabAtkins> una: this is why i think it should be an option<br> <florian> q+<br> <TabAtkins> una: but authors should generally be using a specific algo<br> <TabAtkins> una: but an option could be to let the browser decide, if they don't care as much about a particular combo<br> <TabAtkins> dbaron: i think once we ship the feature it'll be hard to change<br> <Rossen_> ack florian<br> <TabAtkins> color-contrast(unstable-algo-don't-use(1.0) ...)<br> <TabAtkins> florian: agree, we'll be dealing with less fuly-informed authors and teams, who will show the result to someone in approval who won't be caring about code, just result, and even if it's well-intended it might look wrong alter<br> <TabAtkins> florian: even if you told them it could be different that wouldn't matter<br> <TabAtkins> una: i'm afraid if we ship the current contrast algo people wont' update their code, adn pages will be stuck on bad results<br> <Rossen_> q<br> <bkardell_> q+<br> <TabAtkins> miriam: I agree that's a useful use-case and what I'd expect<br> <TabAtkins> miriam: I think it would be useful to recommend to authors to put the algo into a custom prop so it's easy to update later<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: given how broken wcag2 is, we're asking a lot of people to bake wcag2 into their page, and they won't update their code ever<br> <TabAtkins> fantasai: if wcag2 is the only thing we have to offer and we don't have the ability to auto-upgrade it<br> <castastrophe> q+<br> <TabAtkins> fantasai: then even 5 years from now people will be teaching that you use the wcag2 algo<br> <chris> q+<br> <TabAtkins> fantasai: seems harmful to the web and we shouldn't be shipping it as a solution<br> <bkardell_> q-<br> <TabAtkins> fantasai: if we wanted to go down the auto-updating path and ship now, we could ship a more limited version that only gives white or black<br> <TabAtkins> fantasai: that's basic, but it solves a useful problem<br> <TabAtkins> fantasai: text is readable<br> <TabAtkins> fantasai: but for this issue, i think we do need the ability to choose an algorithm<br> <TabAtkins> fantasai: not just because we want authors to change what they use over time, but they also might actually want a specific algo, frmo design or legal perspective<br> <TabAtkins> fantasai: in the future we might have an excellent algo, but the laws in XYZ might require contrast that conforms to wcag2, I want to be able to say I want the color that conforms to awesome-algo and wcag2.<br> <TabAtkins> fantasai: So not just one algo, but 2+<br> <chris> q?<br> <TabAtkins> fantasai: In the case of "most contrasty one", you can only ahve one, but in "reach at least this level" we can offer multiple<br> <bkardell_> q+<br> <chris> q-<br> <TabAtkins> fantasai: I agree that using a function makes most sense so we can put appropriate scale info in<br> <TabAtkins> fantasai: so for this issue proposal is to add one or more algo functions to color-contrast() arg<br> <TabAtkins> fantasai: that accept the numeric level<br> <TabAtkins> fantasai: and this should be one of the prelude args<br> <TabAtkins> castastrophe: so much +1 to that<br> <lea> needless to say, +1 to everything fantasai just said<br> <TabAtkins> castastrophe: from design system perspective, people aren't likely to update this code frequently<br> <TabAtkins> castastrophe: so having generic name function with a default algo that we can update as we go along...<br> <TabAtkins> castastrophe: i don't know if we've changed defaults under the feet<br> <TabAtkins> castastrophe: we've done that a lot in design components, using the bad default for now until we figure it out<br> <TabAtkins> fantasai: i agree with that, but that's a different issue about the default<br> <bkardell_> q-<br> <Rossen_> ack castastrophe<br> <TabAtkins> fantasai: for the purpose of this discussion it's assumed specified<br> <una> q?<br> <una> q+<br> <TabAtkins> castastrophe: was thinking about generic name<br> <TabAtkins> fantasai: name is color-contrast(), and you'd say like color-contrast(wcag(...), black, white)<br> <TabAtkins> una: so this issue is about always requiring a specific color-contrast algo<br> <TabAtkins> fantasai: for now, we can discuss optionality later<br> <TabAtkins> una: def +1 on making it possible<br> <TabAtkins> una: i would like a world where it's not required<br> <fantasai> default algorithm -> https://github.com/w3c/csswg-drafts/issues/7361<br> <TabAtkins> una: we'll discuss that later<br> <Rossen_> ack una<br> <TabAtkins> chris: we can always relax it later if it's required now<br> <TabAtkins> fantasai: so proposal is we add to color-contrast() a number of specific-algo functions accepted as one of its arguments<br> <TabAtkins> dbaron: clarifying - saying the level is optional. does that mean if you don't you get th emost contrasty choice, and if you do you get the first color that meets the level?<br> <TabAtkins> chris: yes, that's already what the spec says<br> <TabAtkins> Rossen_: objections<br> <TabAtkins> lea: what's the reason to get the most contrasty pair? why not just default to a reasonable level?<br> <dbaron> s/if you don't/if you don't give a level/<br> <TabAtkins> RESOLVED: Allow color-contrast() to specify the algo and level, by taking an algo function as an arg<br> <TabAtkins> Rossen_: that's another issue, we'll discuss that later<br> <TabAtkins> una: what if none of the color values work?<br> <TabAtkins> chris: If you give a target and you run off the end of the lsit, you'll get either white or black, whichever is better<br> <dbaron> (what happens if algorithms disagree on whether white or black is higher contrast? :-P)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7356#issuecomment-1202862867 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 August 2022 15:44:25 UTC