[color-4] Clarification of missing color components and parsing

[tiaanl]

In reference to this section in the [color-4] specification:

csswg-drafts/css-color-4/Overview.bs

Line 983 in 69398af

In certain cases,

According to what is mentioned here, I am uncertain whether missing color components should parse to a valid or invalid color. Currently the following are all valid colors:

color(srgb)  // 0, 0, 0
color(srgb 1)  // 1, 0, 0
color(srgb 1 1)  // 1, 1, 0
color(srgb 1 1 1)  // 1, 1, 1

There is also a definition of the color syntax here (https://w3c.github.io/csswg-drafts/css-color-4/#color-function):

<predefined-rgb-params> = <predefined-rgb> [ <number> | <percentage> | none ]{3}

which does not allow any missing components, but does indeed accept the 'none' keyword.

Does this rule make the previously mentioned valid color invalid if they do not have the 'none' keyword in place of the missing components?

color(srgb none none none)  // 0, 0, 0
color(srgb 1 none none)  // 1, 0, 0
color(srgb 1 1 none)  // 1, 1, 0
color(srgb 1 1 1)  // 1, 1, 1

[emilio]

Pretty sure the fact that these parse in WebKit / Blink is a bug. It's super-odd and not particularly useful either. Also, the syntax is rather clear :)

In fact I filed this as https://bugs.webkit.org/show_bug.cgi?id=251152 / https://bugs.chromium.org/p/chromium/issues/detail?id=1410200. But it's probably worth clarifying, @svgeesus / @LeaVerou?

[svgeesus]

Like @emilio I thought the spec was clear but taking another look just now, I see:

One or more s or s providing the parameter values that the color space takes.

This is left over from when we used to auto fill-in omitted values and trim excess values. Which we decided not to do anymore, once color() in CSS Color 4 was restricted to predefined RGB spaces, and we dropped fallback colors.

The grammar itself is clear:

{3}

So I need to clean up that old text to make it once more agree with the grammar.

[svgeesus]

Spec now says

The three parameter values that the color space takes (RGB or XYZ values).

to agree with the grammar.

[svgeesus]

Also, I now see from this issue that the phrase 'missing color component' can be mis-interpreted to mean an author-omitted value, not a powerless component.

[svgeesus]

@emilio wrote:

Pretty sure the fact that these parse in WebKit / Blink is a bug. It's super-odd and not particularly useful either.

This is leftover (previously correct) behavior from when color() accepted a variable-length list of color components. I agree it is now a bug.