[css-color-5] Commas in color-mix()?

[LeaVerou]

Since various UAs are currently implementing, it's imperative that we finalize the syntax of color-mix() ASAP.

I've done a fair bit of editing and clearing up of that section recently, and the current grammar looks like this (note that the adjusters have been removed per editor resolution):

color-mix( in <<colorspace>> && [ [ <<color>> && [ <<percentage>> ]? ] <<color>> ])

Valid usage examples per this grammar:

color-mix(in lch red 20% white)
color-mix(in lch 20% red white)
color-mix(red 20% white in lch)
color-mix(20% red white in lch)

Invalid usage examples:

color-mix(red in lch 20% white)
color-mix(red 20% in lch white)
color-mix(in lch red white 20%)

In previous versions of color-mix(), there were commas to separate the color space argument from the colors. After #6050 we resolved to remove that comma. However, since a comma is a "stronger" separator than a space, if we left the comma between colors, it would look as if the color space argument only applies to one of them:

color-mix(in lch red 20%, white)

So we removed that comma as well.
While I would strongly object to having a comma only to separate the colors but not the color space from the colors, I think the previous all-comma syntax was actually more readable:

color-mix(in lch, red 20%, white)
/* vs */
color-mix(in lch red 20% white)

OTOH this syntax allows for more flexibility in ordering the arguments.

[mirisuzanne]

I tend to agree that the commas add clarity, and would favor that over flexible ordering. As mentioned in the linked issue (#6064), it seems important to me that we establish a relationship between the percentage and the color it applies to. I like that the comma syntax allows me to clearly see the difference between:

color-mix(in lch, red 20%, white)
color-mix(in lch, red, 20% white)

Ideally the colorspace could still be first or last (and eventually optional).

[svgeesus]

Yeah that is a big readability difference.

[LeaVerou]

Ideally the colorspace could still be first or last (and eventually optional).

Note that with the current grammar it can also only be first or last, not in the middle.

[una]

Just wanted to bring up that this might be a bit confusing. in is already a CSS unit value (inch)

[emilio]

I won't be in today's telecon because APAC, so I'll dump my thoughts here.

I do find commas way more readable as well for what is worth.

Ideally the colorspace could still be first or last (and eventually optional).

I'd prefer the order of arguments being as fixed as possible at least for now, actually. The stricter the grammar, the faster it's going to be to parse it, and the more we can extend it in the future without headaches. I'm thinking that there's some parallelism between the color-space argument to color-mix() etc and the direction argument of linear-gradient(), which is also only allowed at the beginning, before the color stops.

My preference would be to settle on something simple at first like color-mix(in <colorspace>, <color> <percentage>?, <color>), then figure out if/how we need to extend such syntax. If we fix the position of the colorspace we can also remove the in keyword of course, though that's more debatable.

[una]

To avoid the in keyword, why not use existing constructs like the /, i.e.

color-mix(red 20%, white / lch)

I do think the comma is necessary here to separate where the 20% belongs to

[LeaVerou]

I think the in keyword adds readability: think of how we say things in English: "interpolate X and Y in LCH". I don't think any confusion with the in unit is likely, since units are prepended by numbers.

In your example @una, I would be unsure whether lch is grouped with white or with red 20%, white. E.g. in background, / has lower precedence than ,. If we use commas to separate top-level units, we should use it to separate all top-level units.

I'm fine with forcing the color space (and other future metadata) to be first. The downside is that it reads somewhat more awkwardly, the upside that it's more consistent with other functions this way (e.g. gradients).

[una]

The color-mix should take place in the same color-space, otherwise wouldn't this cause compatibility issues? I would expect that whichever colors I use in the color-mix, the mixing will be done in the same color space. The colors would get cast to that space and mixed.

That's why I feel that the most straightforward syntax is:

color-mix([ [ <<color>> && [ <<percentage>> ]? ] <<color>> ] / <<colorspace>>?)
color-mix(red 20%, white / lch)

This reads to me as: mix 20% red with 80% white in the lch color space

[svgeesus]

I would expect that whichever colors I use in the color-mix, the mixing will be done in the same color space. The colors would get cast to that space and mixed.

Yes, exactly.

[una]

Or we can swap the color space (though I prefer the color space at the end):

color-mix(<<colorspace>> / ?  [ [ <<color>> && [ <<percentage>> ]? ] <<color>> ] )
color-mix(lch / red 20%, white)

(apologies if this syntax is incorrect).

[LeaVerou]

@una in your grammar there are no commas, but there are in your examples. Assuming the correct version includes commas:

I made this point earlier, but since it was in an edit it may have been lost. In background, / has lower precedence than comma. E.g. background: url(...) center / cover, black. I would be strongly opposed to using the same operators with different precedence in two different CSS properties, this is very internally inconsistent.

[svgeesus]

I do see an emerging consensus that commas are better, at least between the two color-percent pairs