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

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

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 Mar 2020 16:16:19 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-600724751-1584548178-sysbot+gh@w3.org>
> Going from 8 bits to 12 bits: 1 / 16 = 0.0625 which is much bigger than 0.001. So maybe 0.05?

If they're using bit channels like that, then we don't have to worry about rounding; you get an integer when it's exactly an integer value (last four bits are zero), and don't otherwise.

What we have to worry about is things like using float-channel extended sRGB, where it's not guaranteed that we'll get back to an integer value. (Chrome's current plan is to just upgrade its color handling to always be 32-bit float channels in extended sRGB. Our textures will be f16, to reduce memory usage, but CSS colors can afford to pay for the convenience of f32.)

A .001 epsilon is probably fine for a float 32, but .01 is likely fine as well.

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

Still a little confused. Are you thinking that browsers would round to a particular bit depth, *then* write it out in decimal?

They'll just do the conversion to sRGB with floats and serialize the result, using the normal serialization rules.

> That seems to be comparing two floats, alpha and 1.0, which is typically seen as poor practice. Shouldn't that be updated to say that if 1.0 - α > ε for some suitably defined ε?

Yeah, probably. Lower priority since 1 is exactly representable and alpha isn't usually mathed at, but might as well make all these changes together.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4826#issuecomment-600724751 using your GitHub account
Received on Wednesday, 18 March 2020 16:16:21 UTC

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