- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Aug 2022 18:27:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `syntax`, and agreed to the following:
* `RESOLVED: Keywords undefined`
* `RESOLVED: Whatever keywords for foreground/background whatever they are are required`
* `RESOLVED: No keyword ahead of algorithm list`
<details><summary>The full IRC log of that discussion</summary>
<emilio> subtopic: syntax<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/7359<br>
<fantasai> Suggestion is color-contrast([over|under] <color> <contrast-algo>#, <color>#)<br>
<fantasai> Suggestion is color-contrast([over|under] <color> <contrast-algo>+, <color>#)<br>
<emilio> emilio: why a +<br>
<emilio> fantasai: because they're space-separated<br>
<emilio> una: example w/ colors?<br>
<fantasai> color-contrast(over white wcag2(AA), blue, red, green)<br>
<emilio> astearns: which of blue, red, green looks best over white<br>
<emilio> una: I read white as foreground<br>
<emilio> TabAtkins: proposition first because of gradients<br>
<emilio> una: here I expect location + color value<br>
<emilio> fantasai: we intended to read not as a param but a proposition<br>
<emilio> bramus: why not background/foreground rather than over/under?<br>
<emilio> astearns: that also has the same issue<br>
<emilio> fantasai: we could do that<br>
<emilio> una: I can see where it's coming from but I don't know...<br>
<emilio> chris: not sure it has the same ambiguity<br>
<dbaron> this is why I like color-contrast(white over [blue red green], wcag2(AA))<br>
<emilio> lea: can be icons too right?<br>
<emilio> chris: the algorithm is only about text<br>
<emilio> +1 to dbaron<br>
<smfr> i suggest color-contrast(blue, red, green over white using wcag2(AA))<br>
<lea> +1 to fantasai<br>
<emilio> fantasai: we generally put arbitrary long lists at the end<br>
<emilio> una: I'd make contrast algorithm first<br>
<emilio> ... so wcag2, white over blue, green, red<br>
<emilio> TabAtkins: the algorithm could be typed first<br>
<emilio> fantasai: everything before the first comma can be reordered<br>
<emilio> q+<br>
<una> so you could write: `color-contrast(wcag(AA) white over, red, blue, green)`<br>
<emilio> chris: algo can specified against the target, what if you don't have a target contrast?<br>
<una> s/wcag(AA)/wcag2(AA)<br>
<lea> Could we maybe use a keyword before <contrast-algo>+ ? E.g. using <contrast-algo>+? color-contrast(using wcag(aa) ...)<br>
<fantasai> color-contrast(over white wcag(), red, blue green)<br>
<fantasai> color-contrast(over white wcag(), red, blue, green)<br>
<fantasai> or<br>
<fantasai> color-contrast(over white wcag(max), red, blue, green)<br>
<TabAtkins> not `white over`, that would be invalid<br>
<chris> s/wcag(/wcag2(/g<br>
<TabAtkins> specifically because the order you put it in reverses the meaning<br>
<emilio> una: over before the value is hard to read<br>
<astearns> q+<br>
<emilio> dbaron: I think the bracketed list<br>
<TabAtkins> (`over white` and `white over` read as exactly opposite things)<br>
<dbaron> (because they are opposite things!)<br>
<emilio> dbaron: I think the bracketed list was nice but some people don't like that<br>
<astearns> ack emilio<br>
<emilio> fantasai: I think it should parallel gradients<br>
<emilio> lea: also color-mix()<br>
<fantasai> emilio: given confusion about ordering of stuff, can we choose some fixed order?<br>
<fantasai> emilio: if you can reorder this stuff, we are getting confused<br>
<fantasai> TabAtkins: preposition and color have a fixed order<br>
<fantasai> TabAtkins: but algorithms can be moved around<br>
<fantasai> emilio: why do we want to specify multiple algorithms?<br>
<fantasai> T<br>
<fantasai> TabAtkins: example was, if tomorrow someone comes up with the best contrast algo that works perfectly<br>
<fantasai> TabAtkins: but you also need to satisfy WCAG2 for legal reasons<br>
<fantasai> TabAtkins: you will need to specify two algorithms<br>
<fantasai> chris: 2 algos or multiple?<br>
<una> q+<br>
<fantasai> TabAtkins: 1 or more<br>
<fantasai> TabAtkins: you have to pass all the thresholds<br>
<fantasai> TabAtkins: if they disagree on white or black, we prioritize the first specified algo<br>
<fantasai> una: Wouldn't that give us the same problem with color list last?<br>
<fantasai> fantasai: they're not comma-separated, and you will likely only have one or two<br>
<fantasai> una: could space-separate color list<br>
<bramus> q+<br>
<fantasai> TabAtkins: that would prevent us from adding any parameters to the list, which I don't think we want to do<br>
<una> q-<br>
<astearns> I think I’d prefer `white background` and `white foreground` meaning the color is in that slot<br>
<emilio> astearns: I'm not happy with the proposition, I'd rather have a name<br>
<emilio> ... because it's not misinterpretable<br>
<astearns> s/name/noun phrase/<br>
<bramus> q-<br>
<emilio> fantasai: do we want to go for the full word of just fg/bg?<br>
<bramus> had same concern as astearns<br>
<emilio> una: don't mind that<br>
<lea> not abbreviations please!<br>
<emilio> ... I think it's more readable because color is first<br>
<emilio> bramus: background / foreground is clear<br>
<emilio> clearer to me*<br>
<bkardell_> color-contrast(black foreground wcag(), red, blue, yellow) ?<br>
<emilio> una: if we're having foreground/background what about if you have a border or so?<br>
<bkardell_> is that the suggestion?<br>
<emilio> fantasai: I think you pick your contrast algorithm and pick something<br>
<astearns> q?<br>
<emilio> usually it's not equal amounts of colors<br>
<astearns> ack astearns<br>
<lea> q+<br>
<emilio> so that's what you'd use as background<br>
<fantasai> s/usually/fantasai: usually/<br>
<astearns> ack lea<br>
<fantasai> s/so that/fantasai: so that/<br>
<emilio> lea: given most contrast algos don't distinguish bg/fg, could we have a default?<br>
<emilio> ... so that we don't need to specify?<br>
<emilio> chris: so the first one can be one of them?<br>
<emilio> TabAtkins: what about the algo that does care?<br>
<emilio> ... why not make it gramatically required? Some algos don't care numerically but<br>
<chris> wht nt uz abrvnz<br>
<emilio> lea: also can we not do bg/fg (abbreviations)?<br>
<dbaron> dbaron: why not make it grammatically required (just for the algorithms that require it)?<br>
<emilio> ... also can we have a keyword before the algorithm so it's easier to read?<br>
<emilio> TabAtkins: we usually don't do that unless needed for disambiguation<br>
<emilio> fantasai: as long as it doesn't prevent reordering<br>
<emilio> TabAtkins: proposal is a keyword to separate the algos from the rest of the stuff, like put the keyword "using" in front or so<br>
<emilio> fantasai: we don't need it so I don't think we should add it<br>
<emilio> TabAtkins: agreed<br>
<bramus> `color-contrast(<color> [background|foreground] using <contrast-algo>+, <color>#)` then?<br>
<una> +1<br>
<emilio> dbaron: what I was suggesting is to require foreground / background only when using an algorithm that needs it, otherwise optional<br>
<emilio> lea: that's what I meant<br>
<emilio> TabAtkins: so it'd be grammatically invalid to not provide it?<br>
<emilio> dbaron: yes<br>
<florian> q+<br>
<lea> q+<br>
<TabAtkins> color-contrast([ [ <color> [background|foreground] ] && <contrast-algo>+ ], <color>#)`<br>
<emilio> una: related to the following question, auto would always require it<br>
<astearns> ack florian<br>
<emilio> florian: some algos require foreground/background, are there other things?<br>
<emilio> chris: not so far<br>
<emilio> ... there's a proposal to add a third color<br>
<emilio> florian: e.g. to get a numerical value of wcag you don't need font-size, but AA/AAA does<br>
<emilio> ... does that become an input?<br>
<emilio> chris: that's a good question and I think background/foreground is reasonably special<br>
<bkardell_> q+<br>
<emilio> florian: I suspect font-size is quite special too?<br>
<emilio> TabAtkins: you can specify the level as well<br>
<emilio> florian: if you know the font-size<br>
<astearns> ack lea<br>
<emilio> fantasai: since the algorithm takes params we could communicate there<br>
<emilio> lea: that'd make the grammar harder to define that conditional-requirement<br>
<chris> s/third color/third color which is the surround<br>
<emilio> TabAtkins: we'd define it in prose<br>
<emilio> TabAtkins: a bit annoying<br>
<emilio> lea: if we use a default we don't have that problem<br>
<emilio> TabAtkins: yeah but that means that people will forget and get confusing answers<br>
<emilio> lea: maybe mandatory everywhere?<br>
<emilio> TabAtkins: yeah<br>
<emilio> fantasai: I think that'd be fine<br>
<astearns> ack dbaron<br>
<Zakim> dbaron, you wanted to disagree about mandatory everywhere<br>
<emilio> dbaron: I think right now there's only one algo that needs it and is still in flux<br>
<lea> +1 to TabAtkins<br>
<emilio> TabAtkins: I think intuitively, the fact that a lot of algos don't use it is clear that they are garbage, because changing fg and bg significantly changes the perception of contrast<br>
<dbaron> ok, makes sense<br>
<emilio> lea: can we resolve about making bg/fg mandatory?<br>
<astearns> ack bkardell_<br>
<chris> q?<br>
<emilio> bkardell_: lots of the examples colors are just color names<br>
<emilio> ... part of the reason we're doing it at runtime is that you might not have known inputs<br>
<emilio> ... I think the complex case is when you don't have a single color background<br>
<emilio> ... e.g. if you look at the screen what the color name should be?<br>
<emilio> TabAtkins: nobody has put down an algorithm to do that easily<br>
<emilio> bkardell_: I think I disagree<br>
<una> real example, say a button: `color-contrast(lightblue background using wcag2(AA), royalblue, navy, darkblue)`<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to say I'm less happy about typing "background" every time<br>
<emilio> TabAtkins: in any case it's a much more complex problem<br>
<lea> una: `using` was rejected<br>
<emilio> fantasai: I'm happy to make things mandatory, but I'm against adding more boilerplate<br>
<emilio> TabAtkins: that's why I was going for fg/bg<br>
<emilio> lea: over/under aren't that much timing<br>
<emilio> typing*<br>
<emilio> TabAtkins: let's clear<br>
<emilio> florian: front/back?<br>
<TabAtkins> s/let's/less/<br>
<emilio> fantasai: that'd work for me<br>
<emilio> una: issue isn't the naming, was the position<br>
<emilio> astearns: proposed resolution is that the first part of the syntax is color with front/back, applying to that color<br>
<una> `color-contrast(lightblue back wcag2(AA), royalblue, navy, darkblue)`<br>
<dbaron> do we want to consider fore/back rather than front/back?<br>
<emilio> fantasai: as long as they're reorderable?<br>
<TabAtkins> color-contrast( [ <color> && [front | back]? && <algo>? ], <color># )<br>
<smfr> q+<br>
<astearns> ack smfr<br>
<lea> TabAtkins: <algo>+, not ><br>
<una> dbaron -- I think that `fore` might be more confusing<br>
<emilio> smfr: I think having the fore/back not applying to the chosen colors<br>
<TabAtkins> yes, right, typo on my part<br>
<lea> s/not >/not ?/<br>
<emilio> ... logically I'd think "the color I wanna choose is the front color"<br>
<emilio> astearns: so you'd like the modifier in the color list?<br>
<emilio> florian: we had the same problem with gradient direction, to top left, or from top left?<br>
<emilio> smfr: I kinda prefer under/over but we rejected that so...<br>
<dbaron> I told you smfr wanted prepositions :-)<br>
<emilio> TabAtkins: curious about why you think over/under apply to a different thing than front/back<br>
<lea> yeah, I also liked that over/under read more like natural language :/<br>
<emilio> smfr: because it's like writing an english sentence, over <foo> I can remember<br>
<emilio> una: that's why I preferred using too<br>
<fantasai> 1. over/under<br>
<TabAtkins> color-contrast{start:<color>, position:[front|back], choices: <color>+ }<br>
<fantasai> 2. front/back<br>
<dbaron> IMO, "white front" is natural language but "front white" is not.<br>
<fantasai> 3. something else<br>
<florian> 2<br>
<emilio> lea: what were arguments against over under again?<br>
<emilio> chris: confusing order<br>
<emilio> una: you could reorder the first three values<br>
<emilio> fantasai: we wouldn't allow to reorder that<br>
<smfr> i like ‘over|under <color>’<br>
<emilio> +1 smfr<br>
<emilio> fantasai: in gradients we do the same<br>
<lea> +1 smfr<br>
<una> 2<br>
<lea> 1<br>
<bramus> 2<br>
<TabAtkins> 2<br>
<emilio> 1<br>
<fantasai> 1<br>
<astearns> 2<br>
<chris> 2<br>
<miriam> 1<br>
<smfr> 1<br>
<dbaron> abstain<br>
<bkardell_> abstain<br>
<emeyer> abstain<br>
<dholbert> abstain<br>
<emilio> una: core issue is do we want to make sure it's required?<br>
<dbaron> (BTW, with my [] suggestion there's an only-over option where you could write "green over [red white blue]" or "[red white blue] over green".)<br>
<emilio> lea: we concluded it should be required<br>
<emilio> astearns: no consensus<br>
<emilio> TabAtkins: proposal to keep keywords undefined<br>
<emilio> ... poll authors then come back<br>
<dbaron> (6 votes for #2, 5 votes for #1, 4 abstain... since some people voted with /me and weren't logged)<br>
<emilio> RESOLVED: Keywords undefined<br>
<emilio> RESOLVED: Whatever keywords for foreground/background whatever they are are required<br>
<emilio> RESOLVED: No keyword ahead of algorithm list<br>
<emilio> lol<br>
<emilio> TabAtkins: next is comma separation between color list and the rest<br>
<emilio> chris: if I have `over white, green, red, blue` it looks confusing<br>
<emilio> chris: I don't think it makes sense<br>
<bkardell_> fantasai: I had some lag, but yes - what smfr said :)<br>
<astearns> q?<br>
<emilio> chris: that'd look awful<br>
<emilio> TabAtkins: it'd have the keyword before<br>
<emilio> fantasai: agree it's a problem<br>
<emilio> dbaron: same<br>
<emilio> florian: not sure what's better<br>
<TabAtkins> precedence for / is that it's weaker than commas when mixed<br>
<TabAtkins> we have several properties using that<br>
<emilio> lea: right, alternatives are not better<br>
<emilio> astearns: proposal to punt<br>
<emilio> ... (until keywords are decided)<br>
<smfr> +1 to lea<br>
<emilio> lea: right now color-contrast sounds like it returns a contrast, not a color<br>
<dbaron> I like contrasting-color()<br>
<fantasai> contrast-color()<br>
<emilio> ... can we change the name? color-contrasting / contrasting-color?<br>
<emilio> fantasai: I don't like adding ing<br>
<emilio> lea: I think contrast-color works fine<br>
<emilio> una: I like it<br>
<miriam> +1<br>
<emilio> astearns: objections?<br>
<ydaniv> +1<br>
<emilio> chris: I think we had them and then we harmonized with color-*<br>
<emilio> ... but agree it's better the other way<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-1203072807 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 18:27:28 UTC