W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

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

From: Chris Lilley via GitHub <sysbot+gh@w3.org>
Date: Thu, 29 Oct 2020 15:04:19 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-718813812-1603983857-sysbot+gh@w3.org>
> 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?

Internal storage as four 32-bit floats sounds fine (storage as 16-bit half-float would also have met the precision requirements). BTW is the transfer curve for the extended sRGB fully defined for negative values (does the straight portion continue forever or does it have a curve mirroring the positive portion)?

> 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.

Anything originally specified as `color(foo c1 c2 c3 ... cn)` will now be serialized as exactly that (`color(0` in lowercase, exactly one ascii space between component values, etc. See [Serializing values of the color() function](https://drafts.csswg.org/css-color-4/#serializing-color-function-values)

> lab(), same benefits/downsides as color(), but maybe more appropriate as a "universal" serialization format for higher-def colors.

If originally specified as `lab()` or `lch()`, yes. See [Serializing Lab and LCH values](https://drafts.csswg.org/css-color-4/#serializing-lab-lch)

I tried to be explicit about the exact serialization format but if any issues or ambiguities are noticed, please comment on this issue or raise a more specific new one as needed.

> Okay, so you're just making sure that, if a browser is using 12-bit channels, the ε for rounding to integers is smaller than the minimum a 12-bit channel can differ from the integer value.

There is a new issue specifically on [minimum bit depth](https://github.com/w3c/csswg-drafts/issues/5667)

@tabatkins I would appreciate extra eyes on the whole of [Resolving &lt;color> values](https://drafts.csswg.org/css-color-4/#resolving-color-values) and [Serializing &lt;color> Values](https://drafts.csswg.org/css-color-4/#serializing-color-values)

GitHub Notification of comment by svgeesus
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4826#issuecomment-718813812 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 October 2020 15:04:20 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:21 UTC