[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.

[LeaVerou]

In fact, I just realized there is precedent of the opposite of what is being proposed: Commas and slashes on the same level, where the slashes are higher precedence than the commas. In the background shorthand!!

background: url(foo.png) center / cover, url(bar.svg);

Therefore, using slashes with lower precedence than commas makes CSS internally inconsistent.

[svgeesus]

How about the keyword vs then? Of the examples fantasai proposed I prefer the first one, it keeps the current ordering with the background color first, rather than hiding it at the end of the list.

[LeaVerou]

I think a keyword might be the way to go if we want to avoid explicit grouping via a function. What about on or over? color-contrast(tan on wheat, lch(0 0 50), #f00)
Yes, we think of the first param as the "background color", but the contrast formula is commutative.

[svgeesus]

we think of the first param as the "background color", but the contrast formula is commutative.

That is why I prefer vs rather than on or over. Might be less obvious (being an abbreviation of a Latin word, versus) to non-native speakers though?

[fantasai]

@svgeesus vs is fairly well-known, I think. It's used in video game matchups and other places (as an abbreviation, not as the word itself) fairly often. :)

[argyleink]

could we go even less? color-contrast(wheat / tan sienna var(--myAccent) #d2691e)

[fantasai]

@argyleink We could. Though we do usually use commas for lists of alternates.

[css-meeting-bot]

The CSS Working Group just discussed color-contrast needs another comma, and agreed to the following:

• RESOLVED: Use vs in color-constrast function

The full IRC log of that discussion

<heycam> Topic: color-contrast needs another comma
<heycam> github: https://github.com//issues/5087
<TabAtkins> yeah let's move on for the moment
<heycam> leaverou: I can take this
<heycam> ... right now we have the color-contrast function accepting a bg color and a list of fg colors
<heycam> ... supposed to choose the most contrasting color
<heycam> ... the first is space separated, the rest are commad separated
<heycam> ... makes it looks like the two are grouped together
<heycam> ... so this is a syntax issue, how do we make sure the first color stands out, and the comma separated ones are grouped togetehr
<heycam> ... one proposal is to use a comma, like in gradients
<heycam> ... another is to use a keyword like "versus" or "on" or "over"
<dino> document.getElementById("lea").playbackRate *= 0.5;
<heycam> ... another is to use a slash. a problem with that is inconsistent with other CSS, without parens or something, the slash has a different precedence compared to backgrounds
<heycam> chris: one other thing is that the first element is typically a background, but doesn't have to be
<heycam> leaverou: right if you reverse the colors you still get the same result
<heycam> florian: in terms of keywords, "against" might work to avoid indicating which is fg or bg
<heycam> chris: I also liked "vs"
<heycam> ... that would be my first choice
<heycam> AmeliaBR: for keywords, another could be "from"
<TabAtkins> I'm fine with "vs" or a plain comma.
<heycam> ... choosing a contrasting color from the list after
<jensimmons> q?
<florian> "vs" works for me
<heycam> ... syntax wise I prefer slash, but the concern about all the new color functions consistently using slash to separate the alpha value might be an issue
<heycam> leaverou: that's not a problem, grid-row/column uses slash like this
<heycam> ... but if you have slahes and commas at the same level
<jensimmons> q+
<heycam> ... if you have color / color+, it looks like the first two colors are grouped
<heycam> AmeliaBR: I don't think that's an issue or really consistent
<AmeliaBR> `color-contrast(wheat / tan, sienna)`
<heycam> leaverou: is there precedent for the opposite?
<heycam> TabAtkins: it is true that all the places we mix slash and comma, that slash is subordinate to the comma
<heycam> ... don't think that's necessarily a problem, but I'm fine with using a keyword here
<jensimmons> q?
<heycam> ... if we explicitly want to keep slash as a weaker precedence
<heycam> leaverou: also there's an option of using a function
<heycam> jensimmons: I hear people saying they like "vs", but I really don't
<Rossen_> ack jensimmons
<heycam> ... it doesn't feel expected from the PoV of authors
<heycam> ... I appreciate the consistency argument. is there another symbol we can use?
<heycam> leaverou: what about a function, that definitely makes the grouping obvious
<dino> (not so firm) vote for not using the / to avoid this inconsistent grouping/alternate issue, but i like / more than vs
<heycam> AmeliaBR: most cases that means having triple nested parens
<heycam> Rossen_: what about the "from" keyword?
<heycam> ... sounds fairly intuitive
<heycam> florian: if we're going with a keyword, I like vs better
<heycam> leaverou: I like against and vs better than from
<fantasai> +1 to leaverou
<heycam> argyle: [...]
<chris> vs for me too
<AmeliaBR> `color-contrast(var(--fg) from #002, #ffa)` `color-contrast(var(--fg) vs #002, #ffa)`
<heycam> myles: sounds like there's not argreement on keywords
<heycam> jensimmons: I really don't like it
<heycam> fantasai: there's keywords in gradients
<heycam> leaverou: I think the ship has sailed
<dino> LET'S USE EMOJI!
<heycam> argyle: I like keywords but vs doesn't feel right
<heycam> leaverou: to me keywords read like natural language which I think is something to strive for
<fantasai> s/vs doesn't feel right/against feels very English/
<heycam> ... keywords the precedence is still not completely clear
<astearns> prefers keywords to most magic-punctuation syntax
<heycam> myles: I'm not sure that's something to strive for
<fantasai> s/against/against I like against, but it/
<heycam> ... I don't think it'd be a good idea for properties to be full english sentences
<heycam> Rossen_: we also have a resolution to allow commas everywhere!
<AmeliaBR> q?
<heycam> myles: I don't think we do, I posted about that last week
<heycam> AmeliaBR: I think also, while discussing this, important to remember how this function works
<heycam> ... which I wasn't thinking of when I suggested keywords
<heycam> ... but you're picking a value from the list, contrasting it against the first value
<jensimmons> |
<heycam> ... it's the list you're picking from
<heycam> argyle: it sounds nice when you put it that way
<faceless2_> I think a keyword over /, I can't get past the precedence issue. commas just seem naturally lower priority than slash
<heycam> Rossen_: are we more leaning towards using "against"?
<heycam> ... if we used versus would it be abbreviated?
<heycam> florian: I hope so
<heycam> Rossen_: we don't use abbreviations anywhere else?
<heycam> plinss: only every unit type
<heycam> TabAtkins: "vs" is pretty universal
<heycam> dbaron: except in the legal system in the US, where it's "v"!
<TabAtkins> video game *and* movies
<chris> vs
<argyle> vs
<heycam> chris: let's go with vs
<heycam> leaverou: I'm fine with vs
<heycam> Rossen_: any objections to adding vs to the color-contrast function?
<AmeliaBR> ``color-contrast(var(--fg) vs #002, #ffa)`
<Rossen_> color-contrast(wheat vs tan, sienna, var(--myAccent), #d2691e)
<leaverou> color-contrast(wheat vs tan, sienna, var(--myAccent), #d2691e)
<heycam> dino: can someone type an example?
<TabAtkins> color-contrast(wheat vs tan, #00ff00, var(--foo))
<chris> yay!
<heycam> RESOLVED: Use vs in color-constrast function
<argyle> very nice

[argyleink]

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

[svgeesus]

Added vs per WG resolution