`<absolute-color-base>` not enough anymore

[svgeesus]

The notion of <absolute-color-base> was introduced to the grammar of <color> in CSS Color 4 to separate out problematic things like currentColor (which can't be resolved until used-value time and depends on the value of color on that element and its ancestors) or <system-color> which depend on light/dark mode, and forced colors mode

It continued on in CSS Color 5 where it is also used to exclude problematic device-cmyk() (which has no colorimetric basis and might be resolved by an ICC profile or might be an eye-searingly inaccurate naive color conversion

<absolute-color-base> is used directly in the grammar for the override-colors descriptor on @font-palette-values (to exclude currentColor). But there is no good reason to exclude device-cmyk() there.

However, this is no longer sufficient because CSS Color 5 introduces color-mix() and Relative Color Syntax so what used to be a resolvable, colorimetric item like rgb(30% 70% 20%) could now be rgb(from currentColor r g b) or color-mix(in oklab, rgb(30% 70% 20%) 40%, currentColor).

There is still a need to exclude certain problematic color forms for various reasons, but I am now of the opinion that doing this via formal syntax is no longer workable and the exclusion should be case-by-case in prose, instead.

/cc @fantasai @cdoublev @drott @LeaVerou because I have had discussions touching on this in various other issues and would like feedback.

[svgeesus]

So we would have a grammar like

<color> = <color-base> | currentcolor | <system-color> 
<color-base> = <hex-color> | <color-function> | <named-color> | transparent
<color-function> = <rgb()> | <rgba()> |
              <hsl()> | <hsla()> | <hwb()> |
              <lab()> | <lch()> | <oklab()> | <oklch()> |
              <color()> |
              <device-cmyk()> | <color-mix()> | <light-dark()>

[svgeesus]

Related issues:

• [css-colors-5] Minor syntax problems #9445
• [css-color-4] Categories of <color> definition parts #7836
• [css-fonts-4] absolute-color in override-colors unspecified #7010

[cdoublev]

FWIW, I am fine with flattening color sub-productions and excluding some functions or arguments in some contexts in prose, if this cannot be achieved with basic syntax, which seems hard to achieve here, and also with keeping productions that are neither related to parsing/serialization rules (<color-base>, <color-function>), if this can help defining syntax "families".

[tabatkins]

Yeah, that sounds appropriate. I'd still have an <absolute-color> production, just actually define it in prose to be the absolute color formats, and relative/mixed colors using absolute colors as inputs.

[svgeesus]

I'd still have an production, just actually define it in prose to be the absolute color formats, and relative/mixed colors using absolute colors as inputs.

Yup @LeaVerou suggested the same thing to me earlier.

[stiiin]

I'm not sure what would be the most appropriate place to raise this, but I'm starting to think that the spec phrase

Nor are any of those values used inside <color-mix()> or in relative color syntax.

is not entirely true in implementations.

I wrote a little test (GitHub doesn't let me upload *.html, so *.txt will have to do) and see that both Firefox (128.6.0esr) and Chromium (131.0.6778.264) show the same results:

• <device-cmyk()> can't be used inside color-mix(), in line with the spec.
• <system-color> and <light-dark()> can be used inside color-mix(), even though the spec seems to prohibit this behaviour.
• <contrast-color()> can't be used inside color-mix(), and is marked as "invalid property value". This is in line with the spec, but also odd, given the behaviour of the implementations with the other types of color values. (This was the reason why I started looking into this.)
• currentColor can be used inside color-mix(). And although I haven't shown it in my test, it's even treated as valid when it's used for the color property ;)

Is this a point where the implementations and specification are drifting apart, or are they behaving as specified (and am I misunderstanding the spec)?

[cdoublev]

Chrome and Firefox do not currently support device-cymk() and contrast-color(). Therefore only currentcolor, <system-color>, light-dark(), can be tested.

In the relative color syntax, Chrome accepts all relative colors. Firefox only accepts currentcolor.

In override-colors, Chrome and Firefox do not accept relative colors, as specified (and presumably motivated by this comment):

The specified <color> must be an absolute color.

nit: adding "otherwise it is invalid" would be very handy to find it among the syntax rules defined in prose.

I would suspect that any relative color function should not accept relative colors as argument. But both Chrome and Firefox accept any of them in light-dark().