[css-color-4] Serialization/normalization of color() (and other advanced color functions)

[tabatkins]

All of the sRGB-compatible color functions (everything from Color 3) eagerly normalize into an sRGB tuple, and serialize with rgb(), so you lose information about whether it was originally written as #000, hsl(), etc. This lets UAs eagerly translate it into an efficient internal format (a 32-bit int) and not worry about additional details.

How should we serialize color(), lab(), etc? Chrome is looking into implementing, and is currently planning to eagerly convert these into extended-sRGB, likely stored as four 32-bit floats. Which serialization form should we prefer?

Reasonable options seem to be:

• rgb(), with decimals and values outside of [0,255] to represent the extended-sRGB value. Benefit: should be backwards-compatible with at least some existing color code; doesn't require us to distinguish between legacy color formats (which must stay serializing as rgb()) and newer ones. Cons: requires us to define that rgb() supports extended-sRGB.
• color(), with some arbitrary choice of colorspace. Benefit: perhaps clearer, especially if it happens to match the colorspace the author chose. Downside: requires us to carry an extra bit around for whether the color was in a legacy format or not; might still be an unexpected result if you used a different colorspace.
• lab(), same benefits/downsides as color(), but maybe more appropriate as a "universal" serialization format for higher-def colors.

[tabatkins]

@smfr Since y'all just announced support color(display-p3), any opinions?

[smfr]

I don't think we should convert between colorspaces when serializing, and by colorspaces I mean the space the color is represented in internally (so hsl/hwb/rgb/gray are all in the sRGB colorspace, lab/lch are in the Lab colorspace, color(foo, ...) is in the foo colorspace.

So I think color(display-p3, ...) should serialize as color(display-p3, ...), lab() and lch() should serialize as either lab or lch.

We have to then decide howcolor(sRGB, ...) and color(lab, ...) serialize. My slight preference is preserve them as color() functions.

[tabatkins]

Okay, so if we go that way, our current planned impl would have to carry around a colorspace enum as well, so it knows what colorspace to convert back into when serializing.

lab() and lch() should serialize as either lab or lch.

Analogously to rgb() and hsl() both serializing as rgb(), I think both of these should serialize to lab(). (Serializing arbitrary colors to lch() is fraught anyway, since a non-chromatic color doesn't have a unique angle.)

We have to then decide how color(sRGB, ...) and color(lab, ...) serialize. My slight preference is preserve them as color() functions.

I agree.

[svgeesus]

I think both of these should serialize to lab(). (Serializing arbitrary colors to lch() is fraught anyway, since a non-chromatic color doesn't have a unique angle.)

I agree that lab and lch should serialize to lab.

We have to then decide how color(sRGB, ...) and color(lab, ...) serialize. My slight preference is preserve them as color() functions.

Agreed, because that is also clearer for color(prophoto-rgb ...) etc.

[Crissov]

Could browsers always serialize to color() with the color space used, i. e. all level-3 notations would yield color(srgb <red> <green> <blue> / <alpha>)?
Sure, it breaks backwards compatibility, but otherwise it seems like the cleanest solution.

PS: #4649 adds color(lab …) which would make this possible.

[tabatkins]

No, because it absolutely breaks backwards compat of something that has been stable for many, many years and that lots of scripts rely on.

[Crissov]

Do they, though?
I tried to find examples on Github of scripts that assume a particular notation for a serialized <color> (apart from assertions in Blink / Webkit / Chromium conformance test files). Maybe Iʼm searching the wrong way, but I have not found any yet, certainly not using getPropertyValue().

By the way, while reading the respective part of the CSSOM draft, I noticed that

shortest base-ten integer serialization of the color’s [red/green/blue] component

seems underspecified, because it does not say whether the RGB components are [0…255] (apparently intended), [0…100]% or [0.0…1.0].

[tabatkins]

I know that I've written plenty of code that looks at color serializations for various reasons, and I absolutely depend on it coming out as rgb() so I can parse it and do math on it. (Old IE versions instead giving back whatever input format you put in was thus extremely annoying as I had to implement all the named keywords too.) I assume that my experiences aren't unique.

[svgeesus]

So, looking first at what is in CSSOM currently for <color>:

• it links to CSS Color 3 for the definition of the color type
• it picks rgb() or rgba() based on the alpha being 1.0 or not
• it generates the shortest base-10 integer representation of each color component
• it generates a comma-separated list of color components

Questions as I start porting this to CSS Color 4. I'm looking to maximize backwards compatibility but also extend to what CSS Color 4 allows for sRGB values, notably more than 8 bits per component

1. Should this continue to serialize non-unity-alpha as rgba() or should it use rgb() with the optional alpha component?
2. Should this continue to use the still-allowed comma-separated list form, or the newly allowed space-separated-list form?
3. How close to an integer should the value be, to be snapped to an integer serialization?
4. What is the minimum bit depth for non-integer serialization? I assume this should be 12, because rec2020 can use either 10 or 12 bits; the percent form of rgb() can use arbitrary precision.

[svgeesus]

@therealglazou @emilio @tabatkins particularly looking for your input on those questions

[Crissov]

Do you agree that it would be ideal if everything could be serialized to color()? (i.e. without backcompat concerns)

If so, just make the cut already and serialize anything that uses features (notation, color space) beyond what Level 3 offered to color(), even if the author was just leaving out commas in rgb().

it generates the shortest base-10 integer representation of each color component

What does that even mean?
I would have chosen percentages for all four RGBA components, because they are unambiguous and of arbitrary precision.

[svgeesus]

Do you agree that it would be ideal if everything could be serialized to color()?

No, not in the slightest, for reasons that have already been explained.

[tabatkins]

Should this continue to serialize non-unity-alpha as rgba() or should it use rgb() with the optional alpha component?

I don't think we should break from the older pattern here just because the bit depth is higher. So the rgb()/rgba() distinction should be maintained.

Should this continue to use the still-allowed comma-separated list form, or the newly allowed space-separated-list form?

Same.

How close to an integer should the value be, to be snapped to an integer serialization?

Hm, should depend on what depth people can actually distinguish. I presume it would be safe to put the epsilon at .001 or so? For it to not work would require a thousandth of an sRGB unit to be visually distinguishable, which I doubt.

What is the minimum bit depth for non-integer serialization? I assume this should be 12, because rec2020 can use either 10 or 12 bits; the percent form of rgb() can use arbitrary precision.

Not sure I understand the question - are you asking what the smallest bit depth is that could possibly trigger a non-integer serialization? If so, it's 9 bits, right?

[svgeesus]

Going from 8 bits to 12 bits: 1 / 16 = 0.0625 which is much bigger than 0.001. So maybe 0.05?

What is the minimum bit depth for non-integer serialization? I assume this should be 12, because rec2020 can use either 10 or 12 bits; the percent form of rgb() can use arbitrary precision.

Not sure I understand the question - are you asking what the smallest bit depth is that could possibly trigger a non-integer serialization? If so, it's 9 bits, right?

No, I'm asking what is the minimum bit depth that we need to preserve. Since Rec 2020 allows 10 and recommends 12, we need to preserve at least 12 bits.