[css-color-4] Clarify how color() values with fallback should serialize

[weinig]

It is not clear to me from the wording how color() values with fallback (e.g. color(display-p3 0 1 0, srgb 0 1 0)) should be serialized. It would be good to at least have an example, if not explicitly call it out.

[svgeesus]

You are right, this is not covered at all, and should be, explicitly, not just as an example.

In general, the design principles for <<color>> serialization were:

1. For legacy formats, maximal backwards compat so comma separators between color components, etc
2. For the new formats, normalize the values (such as trimming trailing zeroes) but otherwise serialize as-is
3. Normalize fully opaque colors by using an implicit alpha, except for legacy rgb/rgba, hsl/hsla

So it seems therefore that the serialized form, in the case of fallback, should be serialization as-is except for the various normalizations. Does that seem reasonable?

(Note to self to make sure Typed OM also handles fallback colors on the color() function).

Also btw your example is incorrect, it should either be

color(display-p3 0 1 0, rgb(0 100% 0))

using the legacy syntax as a fallback, or

color(display-p3 0 1 0, color(srgb 0 1 0))

using another color function as a fallback. Note that in this second case, the fallback could itself have a fallback. Here is an example:

color(rec2020 0 0 1, color(display-p3 0.119 0 0.415, rgb(14.1% 0% 43.8%)))

[weinig]

Thanks for the details, I'm just starting to look into fallback now, so haven't really studied this part of the spec yet. There are a few examples that don't seem to match this pattern like Example 40 in https://drafts.csswg.org/css-color-4/#color-function.

color(prophoto-rgb 0.4835 0.9167 0.2188, display-p3 0.3499 0.9800 0.1399, rgb(33.44% 96.68% 21.07%))

[weinig]

So it seems therefore that the serialized form, in the case of fallback, should be serialization as-is except for the various normalizations. Does that seem reasonable?

Yeah, that makes sense to me.

[svgeesus]

fallback examples fixed to use the actual grammar

[carlosame]

fallback examples fixed to use the actual grammar

The syntax is supposed to be this:

color() = color( [ [<ident> | <dashed-ident>] [ <number-percentage>+ | <string> ] [ / <alpha-value> ]? ]# , <color>? )

where "Each argument represents either an invalid color, as described below, or a valid color", so

color(prophoto-rgb 0.4835 0.9167 0.2188, display-p3 0.3499 0.9800 0.1399, rgb(33.44% 96.68% 21.07%))

seems correct.

If it is not, then the above grammar should be modified as well. Also, the current one probably meant:

color() = color( [ [<ident> | <dashed-ident>] [ <number-percentage>+ | <string> ] [ / <alpha-value> ]? ]# [, <color>]? )

[weinig]

I guess one other thing that would be good to call out is how are things like the following (taken from wpt predefined-014.html) serialized:

color(banana 0.1 0.2 0.3, #009900)

That is, an invalid color (invalid because it is non-dashed ident representing a color space that isn't predefined) with a valid fallback color.

Similarly, explicitly codifying how something like the following serializes would be helpful:

color(--banana 0.1 0.2 0.3, #009900)

That is, an invalid color (invalid because there is no @color-profile --banana { ... }) with a valid fallback color as well.

(Note, Example 19 makes it clear how this would serialize if there was a specified @color-profile --banana { ... }, though it might be worth calling out that it would serialize the same regardless of whether the src had loaded, if that is indeed the case).

[svgeesus]

(No action pending resolution of #5931 which would make this one moot)

[svgeesus]

Closed because the color() syntax no longer includes a fallback