Re: [csswg-drafts] [css-color-4] Disagreements over gamut mapping (#7610)

@weinig wrote:

> Oh, very interesting. I don't believe that was in the spec when I was last working on this (I made an intentional change to match the spec and to not clamp around a year ago if I remember correctly), so thank you for bringing this to my attention.

You were right (and conforming to other parts of the spec) to avoid clamping.

I dug into this via Git blame and it has in fact been in the spec for over two years, being added [here](https://github.com/w3c/csswg-drafts/commit/7ac7d934a46b9f6ccfee0f3a331dc2261f079381). A couple of points though:

 - At that time, `color()` was not defined over the _extended range_; that change came later. So there was a need (which no longer exists) to bring values into gamut
 - This also predated the whole 'resolving color values' and 'serializing color values' discussions, and addition of those sections to the spec. So the choice of 'computed value' was made ahead of those clarifying discussions

> @svgeesus @LeaVerou, what was the driving motivation behind this change? To me, it has some unfortunate downsides, and I am not clear what you gain from it over the (or perhaps just my) previous interpretation which was that out-of-gamut colors would be preserved all the way to use time.

Indeed, elsewhere in the spec (such as color interpolation) we emphasize that out of gamut colors are preserved as-is for intermediate calculations:

> Colors may be converted from one color space to another and, provided that there is no gamut mapping and that each color space can represent out of gamut colors, (for RGB spaces, this means that the transfer function is defined over the extended range) then (subject to numerical precision and round-off error) the two colors will look the same and represent the same color sensation.
> https://drafts.csswg.org/css-color-4/#color-conversion


So this is not a recent change which you missed; it is basically a leftover piece of spec prose that I missed, which no longer applies because all `color()` functions are defined over the extended range.

> (the benefits being that values round trip cleanly and that you can use things like out of gamut color(srgb ...) to express things like Display-P3 colors, which is a common practice in Apple's graphics stack these days).

Exactly. Also, in the case of gamut mapping for display, there is no reason to do this at **computed-value** time, which then affects round-tripping as you say. Nor should it be at **used value** time (remembering firstly that used value is the computed value after layout, and layout does not affect color; also that getComputedStyle returns the used value for colors, not the computed value). Instead, gamut mapping for display is a much better fit for an [actual value](https://www.w3.org/TR/CSS22/cascade.html#actual-value) which is not exposed to script:

> A used value is in principle the value used for rendering, but a user agent may not be able to make use of the value in a given environment. For example, a user agent may only be able to render borders with integer pixel widths and may therefore have to approximate the computed width, or the user agent may be forced to use only black and white shades instead of full color. The actual value is the used value after any approximations have been applied. 

The user agent being forced to use only colors that the current display can physically produce (like p3 or rec2020 colors on an sRGB display) seems to fit actual values perfectly.


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 25 August 2022 15:22:13 UTC