[css-fonts-4] absolute-color in override-colors unspecified

[drott]

9.2.3. Overriding a colors from a palette: The override-colors descriptor

says:

Value: | [<integer [0,∞]> <absolute-color> ]#

But I can't find a reference for absolute-color. Has the color spec changed after this? I assume the intention is to allow <<absolute-color-base>> | currentcolor but not | <<system-color>> | <<device-cmyk()>>.

CC @litherum @svgeesus

Edit: See below for clarifications re currentcolor.

[litherum]

Yes, IIRC the change that added that grammar also modified the color spec.

[svgeesus]

Bikeshed reports, on building CSS Fonts 4

LINE ~6533: No 'type' refs found for '<absolute-color>'.
<<absolute-color>>

probably because CSS Color 4 has

<pre class='prod'>
	&lt;color> = <<absolute-color-base>> | currentcolor | <<system-color>> | <<device-cmyk()>>

	<dfn>&lt;absolute-color-base></dfn> = <<hex-color>> | <<named-color>> | transparent |
	    <<rgb()>> | <<rgba()>> | <<hsl()>> | <<hsla()>> | <<hwb()>> |
	    <<lab()>> | <<lch()>> |
	    <<oklab()>> | <<oklch()>> |
	    <<color()>>
	</pre>

So, the fix is to change Fonts 4 to use the actual exported term :)

[svgeesus]

Oh I just noticed

I assume the intention is to allow <<absolute-color-base>> | currentcolor

If that is correct, I need to make a different edit. Is currentColor to be included?

[litherum]

I intentionally omitted currentColor . c790f28 is the edit. You can see how currentColor was supposed to be part of the <color> production, not the <absolute-color> production.

[svgeesus]

Okay in that case, what we currently have is correct

[drott]

Thanks for fixing the reference.

Okay in that case, what we currently have is correct

But if it was <<absolute-color>> before, and now we use <<absolute-color-base>>, it means dropping <<absolute-device-cmyk>> - is that intended (I may have missed a continuation of the conversation in #6681 (review).

[svgeesus]

Ah, I see. At the time of c790f28 device-cmyk() had a fallback color so it was necessary to split off an <<absolute-device-cmyk>> with no fallback.

So yes this needs a further edit to add back device-cmyk.

[drott]

I am in favour of excluding currentColor, see also my comment: web-platform-tests/wpt#31517 - font-palette-35.html and font-palette-36.html WPT tests should probably be deleted. (CC @faceless2 )

From an implementation perspective, I find it difficult to resolve currentColor at the time of font instantiation, or vice versa: The time of being able to resolve currentColor is not the time of when the font is getting instantiated (for which resolved/absolute colors are needed). For the purpose of current color usage, I suggest a COLRv0/COLRv1 font that uses color index 0xFFFF in the glyph descriptions (which can't be overridden).

[svgeesus]

Yes, I think we are all agreed that currentcolor should (continue to be) excluded. So yes, I agree WPT using it should be removed.

The remaining question is whether to add the device-cmyk back, which I guess we should do.

[svgeesus]

The remaining question is whether to add the device-cmyk back, which I guess we should do.

@drott see

• <absolute-color-base> not enough anymore #9555