Detail about <number>s in rgb-related color functions and glossary

[sidewayss]

See this codepen: https://codepen.io/sidewayss/pen/qBLqPPa

1. floating point numbers are rounded to integers in the rgb() function, so there's no point in using them.
2. hsl() and hwb() are converted to rgb by the browser and are limited to integer values in rgb(), although achieving whole number changes in rgb() can require fractional changes in the other two functions.

I did not mention 2) in either the hsl or hwb page, though I took a crack at it in the RGB glossary page. I am also not familiar with the various RGB color spaces, but in the CSS color() function, the Adobe a98-rgb color space is represented by a "fractional value" (aka unit interval) between 0 and 1. Not sure how that fits in with this paragraph in the RGB glossary page:

Note that there are other RGB color spaces, like the Adobe RGB color space, that can represent a wider {{glossary("gamut")}} of color than the sRGB color space. The coordinates in sRGB and Adobe RGB are different.

I just committed some edits to the color() function page. CSS needs a more generic type for "number between 0 and 1", or does it exist and I'm unaware of it? <alpha-value> is identical to what is needed, but it is specified as belonging to the alpha value, not opacity or any of the other properties/functions that take a number between 0 and 1 or a <percentage>.

[github-actions]

Preview URLs

• /en-US/docs/Glossary/RGB
• /en-US/docs/Web/CSS/color_value/color
• /en-US/docs/Web/CSS/color_value/hsl
• /en-US/docs/Web/CSS/color_value/hwb
• /en-US/docs/Web/CSS/color_value/rgb

(comment last updated: 2023-09-08 16:44:18)

[sidewayss]

I just noticed the "Flaws (1)" indicator. Should I remove the reference to "/en-US/docs/Glossary/GLSL"?

[yarusome]

The CSS Color spec does allow non-integers for these functions, though.

---

For rgb():

<legacy-rgb-syntax> = rgb( <percentage>#{3} , <alpha-value>? ) | rgb( <number>#{3} , <alpha-value>? )
<modern-rgb-syntax> = rgb( [ <number> | <percentage> | none ]{3} [ / [ <alpha-value> | none ] ]? )

(Note it's <number> instead of <integer> in there.) And:

Implementations should honor the precision of the channel as authored or calculated wherever possible. If this is not possible, the channel should be rounded towards +∞.

---

For hwb():

hwb() = hwb( [ <hue> | none ] [ <percentage> | <number> | none ] [ <percentage> | <number> | none ] [ / [ <alpha-value> | none] ]? )

---

For color():

color() = color( <colorspace-params> [ / [ <alpha-value> | none ] ]? )
<colorspace-params> = [ <predefined-rgb-params> | <xyz-params> ]
<predefined-rgb-params> = <predefined-rgb> [ <number> | <percentage> | none ]{3}

[sidewayss]

It's up to you guys if you don't want to document the integer rounding. All the browsers do it. The rgb, hsl, and hwb functions are limited to 16,777,216 colors in the browsers, and the latter two are always converted to rgb. If you want floating point values for RGB you must use the color function and one of the RGB color spaces.

I've never seen the <integer> type used in the docs, but I haven't reviewed all the docs. What CSS properties or functions are spec'd to take only <integer> not <number>?

The docs page for <integer> says:

When animated, values of the data type are interpolated using discrete, whole steps. The calculation is done as if they were real, floating-point numbers; the discrete value is obtained using the floor function.

For these color functions the values are rounded, not floored (truncated).

[sidewayss]

IMO it's fine to say that floating point numbers are accepted, as they certainly are, but there should be a clear statement of the fact that they will be rounded, and probably a mention of why/how that works relative to the other color functions/spaces that don't round, i.e. 16.78M colors, hsl and hwb converted to rgb, etc.

Also note that for better or worse, this PR has a couple of other changes that have nothing to do with the rounding of numbers. See the change to the hwb function page, for example. Each change is small enough that I thought it would be OK to group them together.

[yarusome]

After further checking 15.2. Serializing sRGB values from the spec (emphasis mine):

The precision with which sRGB component values are retained, and thus the number of significant figures in the serialized value, is not defined in this specification, but must at least be sufficient to round-trip eight bit values. Values must be rounded towards +∞, not truncated.

Note: authors of scripts which expect color values returned from getComputedStyle to have component values, are advised to update them to also cope with .

…the linked WPT test (especially the "Property color value 'rgb(2.5, 3.4, 4.6)' [Tests that RGB channels are rounded appropriately]" test), and w3c/csswg-drafts#1983, I think it is more future-proof to avoid stating that implementations limit the number of sRGB colors to an explicit quantity.

To make the edits less intrusive, a note could be added at the end of the "Values" section on each of hsl(), hwb(), and rgb():

Note: This functional notation serializes to sRGB values, and the values of the red, green, blue components may be rounded. in serialization.

---

I've never seen the <integer> type used in the docs, but I haven't reviewed all the docs. What CSS properties or functions are spec'd to take only <integer> not <number>?

E.g. column-count and z-index.

---

The datails of how rounding of <number>s interacts with animation could be omitted (in my opinion) since they add a lot of complexity to the reference page but only deal with a hardly perceivable and transient process.

[sidewayss]

I have committed all your review changes. Please let me know if there is anything else I can/should do to complete this PR. I assumed that your review comments required no further action, sorry if that was incorrect. These two suggestions from your last comment are still outstanding:

To make the edits less intrusive, a note could be added at the end of the "Values" section on each of hsl(), hwb(), and rgb():
Note: This functional notation serializes to sRGB values, and the values of the red, green, blue components may be rounded. in serialization.

The datails of how rounding of s interacts with animation could be omitted (in my opinion) since they add a lot of complexity to the reference page but only deal with a hardly perceivable and transient process.

[sidewayss]

Note: authors of scripts which expect color values returned from getComputedStyle to have component values, are advised to update them to also cope with .

Markup here removed key parts of that quote;

Note: authors of scripts which expect color values returned from getComputedStyle to have <integer> component values, are advised to update them to also cope with <number>.

I am not a graphic artist or color expert, I'm a programmer. My perspective on this is limited, and tainted by this blog post: https://developer.chrome.com/articles/high-definition-css-color-guide/, in that I see the rgb, hsl, and hwb functions as low-definition and the rest of the color functions as high-definition. The integer rounding fits into this perspective, as wrong as it might be relative to the spec.

[sidewayss]

I made your first pending suggested change and pushed the changes. I know I saw the section you refer to in your second pending suggestion, but I can't find it now. This is your suggestion, where is the text that discusses rounding in animations?

The details of how rounding of s interacts with animation could be omitted (in my opinion) since they add a lot of complexity to the reference page but only deal with a hardly perceivable and transient process.