[css-color] Unnecessary comma in color()

[tabatkins]

color()'s grammar is:

<ident> , <args> , <alpha>?, <fallback>?

The comma between the args and alpha is required, as we don't know how many args they are and both can be numbers. The comma between the fallback and the preceding stuff isn't strictly necessary, but it's pretty natural and matches up with other function's fallback arguments.

But the comma between the colorspace name and the arguments isn't necessary. There's no grammatical ambiguity possible, nor any strong tradition of comma usage in similar situations.

Can we remove it? Then we won't need any commas in the common case, like color(adobe-rgb 255 0 0).

[svgeesus]

As long as we don't allow the ident and the args to be freely intermixed, like color(127 foo 255 64). Because for named color profiles, the arglist includes identifiers not just numbers.

[frivoal]

Right, as long as the color profile name comes first, we're good. I'm in favor of Tab's proposed change (though I don't care strongly).

[zcorpan]

SGTM

[grorg]

I don't have a strong opinion, but I'd like to avoid a situation where we have this:

color(adobe-rgb 0.5 0.5 0.5, 0.5)

1. That single comma looks weird, and people will have to remember to use it. Let's avoid a case where people have to think, even for a microsecond, whether they need to add a comma, and punish them if they get it wrong (e.g. gradients)
2. As I commented on twitter, in the vast vast vast majority of these cases, the implementation and the author will know how many color parameters are necessary, and therefore where the alpha is.
3. And in the very very very small set of cases where the implementation doesn't know how many color parameters are necessary, implementations will have to delay processing the parameters anyway. There is no point knowing the alpha before you know the color. And the page author isn't in much danger here - they were the ones who linked to the unusual profile.
4. If the fallback is existing color syntax, then we don't need a separator. It starts with #, rgb or an ident.

[tabatkins]

Okay, you wanna be radical, let's be radical:

1. Remove all commas from color().
2. Drop that janky <alpha-value> nonsense, and just use <percentage> for the alpha. (Allowing multiple ways to write each arg is, I think, one of the mistakes of earlier color functions.)
3. Add an srgb predefined colorspace.
4. Let the colorspace be optional, and default to srgb.
5. Also remove commas and restrict alpha to %s in all the new color functions: lab(), lch(), gray(), hwb().

We can then treat rgb()/rgba() as legacy syntaxes for specifying RGB colors (and hsl()/hsla() are already legacy, since hwb() is more intuitive for srgb stuff, and lch() is generally better overall).

(I'm not being facetious, I think this whole list is a great idea.)

[frivoal]

With the caveat expressed in #275 (comment) (if we make the color space optional, I'd prefer to keep the coma after it), I'm OK with Tab's proposal.

[grorg]

This is rad!

1. 👍
2. I don't like percentages. The rest of the industry uses 0-1 floats for all these values. I would like to just go with that. Think of the bytes we'd be saving! And the "5" keys!
3. 👍
4. 👍 (which I guess is what I proposed in [css-color] color({num}3,4) "shorthand"/alternate for rgb #275)
5. See 2.

[svgeesus]

1. meh. I think it is less readable if there is a long arglist. Consider color(foo, 0.2 0.3 0.4 0.5 0.6) is that a colorspace with five params, or one with four and an alpha? (note that this is a human readability argument, not a parsing difficulty argument)
2. Agree with dinio, percentages here go against industry practice.
3. yes
4. yes
5. see 2.

[LeaVerou]

1. Given that color spaces can have any number of arguments, I think it's an important distinction for readability whether color(foo .1 .2 .3 .5) is a color with 3 params that is 50% opaque or a fully opaque color with 4 params.
2. One of the tenets of good usability is the robustness principle: "be conservative in what you do and liberal in what you accept from others". Since there is no ambiguity, I think both percentages and floats should be allowed as alpha values. Especially since existing color functions accept floats, so not allowing them in color() is bound to create a ton of confusion.
3. 👍, in fact I believe this is one of the resolutions in the SF meeting.
4. 👍
5. See 2.

I'm also not sure about dropping the comma between the color space and its params either. When things in CSS are space-separated, people expect to be able to use any order, unless there is an obvious ambiguity (e.g. all numbers). I think when there is a specified order, it's more clear to have a comma.