Re: [csswg-drafts] [css-color-6] color-contrast() should distinguish foreground and background (#7359)

The CSS Working Group just discussed `color-contrast should distinguish fg from bg`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Subtopic: color-contrast should distinguish fg from bg<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7359<br>
&lt;TabAtkins> chris: Most of the algos, you give two colors, and they generally denote one of them is lighter and the other is darker<br>
&lt;dbaron> (when skimming the list of algorithms you referenced... I only saw APCA that cared which was fg/bg)<br>
&lt;TabAtkins> chris: At least APCA, and som eothers, requires you to say which is the text and which is bg, and if you swap you don't get the same number<br>
&lt;TabAtkins> chris: wcg doesn't care<br>
&lt;una> q+<br>
&lt;TabAtkins> fantasai: two proposals in the issue<br>
&lt;TabAtkins> fantasai: both of them are suggesting an over/under keyword<br>
&lt;TabAtkins> fantasai: one of them puts it as first arg color-contrast(over white, ...) meaning white is bg<br>
&lt;TabAtkins> fantasai: this follows same pattern as gradients<br>
&lt;TabAtkins> fantasai: downside is because arg is a color, it looks like part of the color list<br>
&lt;TabAtkins> fantasai: other suggestion was to use keyword as divider color-contrast(white under ...)<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/7359#issuecomment-1158668669<br>
&lt;TabAtkins> fantasai: argument against was it felt a little backwards about which keyword you used<br>
&lt;castastrophe> q+<br>
&lt;TabAtkins> lea: the way the comma works, it tends to have higher precedence than just words<br>
&lt;TabAtkins> lea: so using a word to separate from a comma-seaprated list, it looks like you have one big first entry in the list<br>
&lt;Rossen_> ack una<br>
&lt;TabAtkins> lea: But that's a problem with the current syntax<br>
&lt;dbaron> +1 to lea about comma versus space precedence<br>
&lt;TabAtkins> una: have we considered a slash rather than comma? like `red over / &lt;color-list>`<br>
&lt;TabAtkins> una: seems to make it easier to separate<br>
&lt;lea> q+<br>
&lt;Rossen_> ack castastrophe<br>
&lt;TabAtkins> castastrophe: i love that solution<br>
&lt;TabAtkins> castastrophe: like the natural language read of "color over"<br>
&lt;TabAtkins> castastrophe: +1 to slash<br>
&lt;Rossen_> ack dbaron<br>
&lt;Zakim> dbaron, you wanted to suggest []<br>
&lt;TabAtkins> dbaron: suggest bracketed list<br>
&lt;TabAtkins> dbaron: grid tracks do this<br>
&lt;bramus> q+<br>
&lt;chris> +1 to a slash or some other way of grouping the list<br>
&lt;TabAtkins> una: my first thought was bracket list<br>
&lt;astearns> so `red over [&lt;color-list>]`<br>
&lt;TabAtkins> una: just think it's more of a convention to use the slash<br>
&lt;Rossen_> ack lea<br>
&lt;TabAtkins> lea: issue with nested function...<br>
&lt;TabAtkins> TabAtkins: not function, just brackets around the color list<br>
&lt;TabAtkins> lea: oh, that's different<br>
&lt;TabAtkins> lea: we have a precedent of using slashes to separate parts within comma list, in backgrounds, so using it here with opposite precedence<br>
&lt;bramus> q-<br>
&lt;fantasai> TabAtkins: That was going to be my objection as well<br>
&lt;chris>  looks like an array: white over [red, blue, violet]<br>
&lt;TabAtkins> fantasai: suggest we bikeshed over lunch<br>
&lt;bkardell_> 👉 red, black 👈<br>
&lt;TabAtkins> &lt;br dur="1h 10m"><br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7359#issuecomment-1202881391 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:52:13 UTC