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

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-color-4] Serialization/normalization of color() (and other advanced color functions) ==
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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4826 using your GitHub account

Received on Wednesday, 4 March 2020 17:24:54 UTC