[cssom][css-color] Need clarification on serialization of rgb & rgba in light of css-color-4's syntax changes

[dholbert]

CSSOM has an explicit algorithm for how to serialize CSS values. For colors, it says to serialize as rgb() vs rgba() depending on whether they have an alpha of one:

If is a component of a resolved or computed value, then return the color using the `rgb()` or `rgba()` functional notation as follows: 1. If the alpha component of the color is equal to one, then return the serialization of the `rgb()` functional equivalent of the opaque color. 2. If the alpha component of the color is not equal to one, then return the serialization of the `rgba()` functional equivalent of the non-opaque color.

https://drafts.csswg.org/cssom/#serializing-css-values

This makes perfect sense, in a world where rgb()/rgba() syntaxes differ (and where only rgba() allows for transparency).

HOWEVER, css-color-4 is broadening the rgb() syntax so that it accepts transparent colors. It only mentions rgba() as an afterthought, as an alias "with identical grammar" to rgb, which only exists "for legacy reasons":
https://drafts.csswg.org/css-color-4/#rgb-functions

SO: now that rgba() is a legacy alias, and it's trivial to serialize transparent colors with rgb(), should we simplify the CSSOM serialization algorithm to always use rgb()? Or should we hold onto its dependence on rgba(), for backwards-compat purposes with websites that might expect the old serialization behavior?

And, in particular -- if an author specifies e.g. color: rgb(10,20,30,0.5), are implementations expected to serialize that with rgba even though the author used rgb?

[cabanier]

If an author used rgb(10,20,30,0.5), that should be the way it's returned in the computed style.
CSSOM has to be updated to reflect this.

[dholbert]

Pushing back slightly: what would be the point of maintaining state about whether the author used rgb vs rgba? If we're going to that trouble, should we also record whether the author used comma syntax vs. comma-less syntax, so we can faithfully recreate their chosen syntax when serializing, too? (I hope not. I'm just not sure where to draw the line on which of the author's stylistic choices get preserved for serialization.)

[cabanier]

The value doesn't need to be returned exactly the same way it was set. If an author uses the new syntax, it would be weird if the computed style reflects to old legacy syntax.
We will likely need both.

[SebastianZ]

Note that the authored syntax is needed for debugging purposes. (Every browser development tool has an option to switch the display of colors to the authored value.)

Besides that, I think it's fine to compute legacy rgba() values to rgb() with alpha channel as long as that change is web compatible.

Sebastian

[cabanier]

as long as that change is web compatible.

It's very likely that this is not the case as it will change existing behavior and script won't see the alpha anymore or get confused about the extra parameter

[SebastianZ]

as long as that change is web compatible.

It's very likely that this is not the case as it will change existing behavior and script won't see the alpha anymore or get confused about the extra parameter

Yes, it's likely. Though that's something that should be checked.

Sebastian

[tabatkins]

I suspect that we're trapped by legacy compat, and have to keep the existing CSSOM rules. If anyone would like to try and serialize to rgb(), tho, please be my guest.

[astearns]

#1004 (comment) has resolutions for this issue

[svgeesus]

All dealt with, CSSWG resolutions implemented, see see Serializing alpha values and Serializing sRGB values

SO: now that rgba() is a legacy alias, and it's trivial to serialize transparent colors with rgb(), should we simplify the CSSOM serialization algorithm to always use rgb()? Or should we hold onto its dependence on rgba(), for backwards-compat purposes with websites that might expect the old serialization behavior?

CSS WG decided to go with legacy compat as much as possible. So values with a fully opaque alpha are output as rgb() while any other alpha value is output as rgba(). Also for compat, the serialization uses the older, comma-based syntax. Again for compat, values are output in a 0 to 255 range, but as number so 127.5 is legal; and with mandatory trimming of trailing zeroes and any trailing decimal point. Thus 32.000 gets output as 32 which is fully backwards compatible for values originally specified with 0-255 integer components; while still allowing higher precision for values originally specified as the percent form.

And, in particular -- if an author specifies e.g. color: rgb(10,20,30,0.5), are implementations expected to serialize that with rgba even though the author used rgb?

They are now, yes.

@dholbert do these edits resolve all of your concerns?