[css-color-5] Should relative `rgb()`/`rgba()` and relative `hsl()`/`hsla()` serialize exactly as declared? about csswg-drafts

[kbabbitt]

The spec goes on to state:

The serialization of the result of a relative color function depends on whether the keyword currentColor is the origin color. If so, the result is serialized as the declared value. This allows the correct value to be used on child elements whose color property has a different value. Otherwise, it is the resolved value, which is a <color>, as defined in CSS Color 4 §  15. Serializing <color> Values.

I understand this to mean:

1. If the origin color is currentColor, then serialize the spelling as declared. (We don't know the origin color and thus cannot canonicalize it.)
2. If the origin color is not currentColor, then resolve the relative color and serialize canonically as described in Color 4.

There are few tests with examples for how canonicalization happens in case 2: color-valid.html, color-valid-rgb.html, color-valid-hsl.html. Notably:

• hsla(...) canonicalizes to equivalent rgba(...), and hsl(...) canonicalizes to equivalent rgb(...)
• rgb(...) is used if the clamped alpha is exactly 1, otherwise rgba(...) is used

cc @svgeesus to confirm.

[weinig]

I filed a separate issue on the ambiguity here - #10305, as I don't think the current spec text is clear on what the rules are.

Regardless of that however, the question posed here remains, as you can just set currentColor as the origin:

That is, should:

rgb(from currentcolor r g b)

and

rgba(from currentcolor r g b)

serializations maintain the exact spelling of function name.

@kbabbitt, the tests you mention, notably, cover the absolute case, which has clear rules about which spelling to do, and those rules are not about what spelling was used at the declaration site, but rather about the resolved value of the alpha channel. As you might not know the value of the alpha channel in a relative color, the exact same rules can't be followed.