[css-color-4] Spec doesn't specify whether implementation must honor <decimal> in rgb/rgba or if it can truncate to an <integer>

[csnardi]

The RGB functions: rgb() and rgba() states that:

These values come from the fact that many graphics engines store the color channels internally as a single byte, which can hold integers between 0 and 255. However, the CSS syntax allows full <number>s, not just <integer>s, for authoring convenience.

However, this section of the spec is unclear as to whether an implementation must try to honor the color channels with decimals preserved or if the implementation can truncate/round the <number> to an integer. Edge has implemented this part of the spec, and appears to simply truncate the number. Chromium is thinking about implementing it, but wants to clarify this section first.

[svgeesus]

Thanks for opening this, agree it needs to be clarified. The "for authoring convenience" is misleading and should be removed. This isn't just syntactic sugar.

Especially given the move to 10-bit and 12-bit per channel, the intent of the the reason is to allow greater precision. Whether implementations should or must store the greater precision needs to be discussed. This also affects serialization.

[tabatkins]

We make no guarantees whatsoever on numeric precision - UAs can store data at whatever precision they want to store it at. They could do 4-bit color if they felt like it, it would just be ugly on anything more modern than a console.

[annevk]

Rounding seems reasonable, but serializing an integer sometimes and sometimes something containing a dot seems like asking for trouble.

[annevk]

The other problem here is that if two UAs both use say 8-bit it's unclear whether 254.5 means 254 or 255. I think if UAs use an equal amount of bits they need to have the same behavior.

[Nadya678]

Is anyone able to see this difference? Btw. Rounding not truncating if answer is "yes". There is possible many of these "problems" for example opacity 0.99999 shall be rounded or truncated?

[svgeesus]

Is anyone able to see this difference?

As we move to wider gamuts and higher dynamic range then yes, banding due to rounding to 8 bits is visibly noticeable. For sRGB, not really.

[tabatkins]

Yeah, specifying the required rounding behavior would probably be good.

[annevk]

We should also have tests ensuring the serialization of CSS colors used on <canvas> are not affected. At least not until <canvas> supports more than 8 bits.

And also, given that we require 8 bits there, I think we should require that as a minimum in CSS too for a browsers conformance class.

[tabatkins]

Yeah, for a browser conformance class 8 bits is a reasonable minimum.

(@fantasai and I tried to write up a comprehensive set of required minimums for CSS some time ago, but there was still too much variation between browsers. In particular, Opera did a lot of trickery with shoving multiple properties into the same bit field, so they had less bits available for values than you'd naively expect. That might be more plausible now.)

[csnardi]

Since there are some errors in the WPT rgb tests for decimals (fixed in web-platform-tests/wpt#8538), I didn't realize Firefox has also implemented decimal channel parsing. As a result, I decided to do a comparison of Edge and Firefox. While Edge truncates decimals, Firefox rounds them (so in Edge 221.5 goes to 221 whereas in Firefox it would go to 222).

It seems important to clarify this issue. Rounding would likely be more "accurate" than truncating, since it would always create a value closer to what was originally intended when compared to truncating.

[svgeesus]

Rounding would likely be more "accurate" than truncating, since it would always create a value closer to what was originally intended when compared to truncating.

Yes, clearly rounding is correct here