[css-color-5] color-contrast needs another comma

[tabatkins]

The color-contrast() function is defined with the grammar:

color-contrast() = color-contrast( <color>  <color>#  )

This produces the odd (to my eyes) usage like color-contrast(wheat tan, sienna); the lack of a comma between wheat and tan looks very strange!

This sort of "space-separate some initial values from a comma-separated list" grammar only shows up in the 'font' shorthand, where it's also weird and confusing; other places where this sort of grammar happens, like gradients, we instead separate the initial stuff from the list-valued stuff with another comma. While this isn't strictly required for parsing, it makes the function read much better.

So the grammar should instead be:

color-contrast() = color-contrast( <color> , <color>#  )

[fantasai]

So... in the gradient functions, the initial arguments are definitely not the same syntax as the items in the list that follows, so it's clear that they're the initial args. But here, it just looks like a list of colors. It's not clear from the syntax that the first argument is the one that's special, and the rest are a list of peers.

Note: comma (rather than space) should be used for separating alternates, so using comma in the selection list is correct.

I'm not sure what a good syntax would be, but it would be nice if the specialness of that first color was more obvious.

Maybe using a slash? It has more visual impact than the space (and also spaces are usually subordinate to commas, whereas the order of precedence wrt slashes is less obvious)... still feels a bit odd.

color-contrast(wheat tan, sienna, var(--myAccent), #d2691e)
color-contrast(wheat, tan, sienna, var(--myAccent), #d2691e)
color-contrast(wheat / tan, sienna, var(--myAccent), #d2691e)

[fantasai]

@tabatkins suggests maybe using a keyword (like we do in gradients), so a few more options could be:

color-contrast(wheat vs tan, sienna, var(--myAccent), #d2691e)
color-contrast(vs wheat, tan, sienna, var(--myAccent), #d2691e)
color-contrast(tan, sienna, var(--myAccent), #d2691e vs wheat)

[svgeesus]

This produces the odd (to my eyes) usage like color-contrast(wheat tan, sienna); the lack of a comma between wheat and tan looks very strange!

It does, but if I understand correctly the new world of comma usage means that commas are used to separate alternatives. Which is why we don't recommend rgb(r%, g%, b%) anymore as green is not an alternative to red.

So the first argument (wheat) has a single value while the second argument is a comma-separated list of alternatives.

I'm not against the use of a separator but that separator should not be a comma.

I like the suggestion by @fantasai to use a slash.

[svgeesus]

@una @argyleink @LeaVerou thoughts on a suitable separator?

[LeaVerou]

The separator should definitely not be a space. Spaces are less separating than commas (think of natural language) so it looks like the first two colors are grouped together and separated from the third.

I'd support a keyword if there was a natural fit, but that doesn't seem to be the case, and unnatural keywords are worse than other solutions. Not sure about combining slashes and commas either, I can't think of any precedent and I think for most people their relative precedence is undefined.

There is precedent here for commas: In gradients, the gradient parameters are comma-separated from the color stop list, even though they are not part of the alternatives listed. I'd vote to just go with that here too.

[argyleink]

I really like the slash syntax color-contrast(wheat / tan, sienna, var(--myAccent), #d2691e); reads nice and feels consistent enough with other uses.

That mean the spec would update to?

color-contrast() = color-contrast( <color> / <color># )

[tabatkins]

It does, but if I understand correctly the new world of comma usage means that commas are used to separate alternatives.

Remember that this is just the old world of comma usage, but used consistently across both properties and functions. So just ask yourself "how would I design a color-contrast property that needed to take these values?". (And pretend that the answer can't be "I'd split it into multiple properties because this is too complex" ^_^)

---

Thinking on this a bit more, I think I do prefer the /. It satisfies our usage patterns for / - we use / when we need a separator other than a space, but the separation isn't appropriate to use commas.

[svgeesus]

In gradients, the gradient parameters are comma-separated from the color stop list, even though they are not part of the alternatives listed. I'd vote to just go with that here too.

Using comma to separate the first color from the list of colors, which is itself a comma separated list, really buries the fact that the first color is special.

The slash looks much more reasonable to me.

[LeaVerou]

FWIW in color-contrast(wheat / tan, sienna, var(--myAccent), #d2691e) wheat / tan feels grouped to me, i.e. I perceive / as having higher precedence than ,.
But it looks like I may be in the minority.

[tabatkins]

I definitely can read it that way, and considered it when I was figuring out which syntax I preferred. But we use / in various contexts, so its precedence is already somewhat fraught.

(I think the only way to make the intended grouping unambiguous would be to more explicitly group the list, like c-c(wheat vs (tan, sienna, ...)), but I don't think that level of syntax divergence is warranted just for this.)

[LeaVerou]

But we use / in various contexts, so its precedence is already somewhat fraught.

Where do we use both / and commas?

[argyleink]

do these count as places we use both, or is this just both coexisting?

grid: autoflow 1fr / repeat(auto-fit, minmax(1fr, 50ch));
background-image: linear-gradient(to bottom, lch(50% 0 0 / 20%), 25%, lch(30% 0 0 / 10%));

[LeaVerou]

@argyleink In both of these, there are parentheses to enforce the grouping. I was asking if there are cases where the slash and the commas are on the same level, like what is proposed here.