relative colors when origin is beyond gamut of output

[estelle]

Once the PR #32004 is merged, but we should address the following :

What happens if you do a relative color with the origin color being outside the gamut of the function? For example, if you use a custom property of a fantastically vibrant magenta using oklab() and add opacity using rgb() as the output. In this case, only the alpha value changed, but I assume the origin color is converted to color(srgb) rather than rgb(), which doesn't matter in the alpha case, but does matter if the value of b is changed.

Originally posted by @estelle in #32004 (comment)

[romainmenke]

Nothing in particular happens.

color(from oklch(90% 90% 0) srgb r g b)

is equivalent to

color(srgb 1.529 0.104 0.833)

There is no gamut mapping at any of the intermediate stages.

In practice this means that you get exactly the channel values you would expect.
If you have a very vibrant red, then your r channel will be larger than 1.

We associate oklch with "wide gamut" and srgb with the srgb color space but color(srgb ...) can express the same range of color values as oklch. The same is true for all other combinations.

You can play around with the channel values here : https://preset-env.cssdb.org/blog/relative-color-syntax-channel-values/

[romainmenke]

Re-reading the title I think I understand the question better :)

The result of a value described with relative color syntax is a <color> value.
<color> values are not restricted to any color gamut.

The output that you see when inspecting computed values in a browser is a serialization of the underlying <color> value. It does not imply color gamut limitations.

This is also exactly why relative colors and color-mix() appear as color(srgb ...) for rgb(from ...) and color-mix(in srgb ...). These notations also do not have any limits and can express all possible <color> values.

[estelle]

The current relative color PR doesn't mention examples like: what happens if we havergb(from var(--foo) calc(r - 1) g b) and --foo: oklch(90% 90% 0).

In this example, I am assuming this oklch is beyond the scope of #[0-9a-f]{6}, but if it isn't, assume some other color that is outside of the RGB() syntax (but still a valid color(srgb) value.

We don't have any examples in the relative color documentation showing how to handle the calculations.

Basically, using pseudo-code, and assuming --foo is beyond the scope of being represented by #[0-9a-f]{6}:

1. if we have rgb(from red calc(r-1) g b) the output is the color(srgb) equivalent of rgb(254 0 0)!
2. if we have rgb(from red calc(r+1) g b) the output is the color(srgb) equivalent of rgb(256 0 0)?
3. if we have rgb(from var(--foo) calc(r+1) g b) the output is the color(srgb) equivalent of rgb(A B C)?

We have explained 1 fully in the current PR, 2 can be inferred from that PR. 3 is not explained in #32004, . How would we calculate/show adding 1 to a value that is between -1 and +1 or -0.4 and +0.4

[romainmenke]

There isn't any difference between 1, 2 and 3.
I am also unsure if adding a variable in the mix is supposed to trigger different behavior?
Because it doesn't change things :)

rgb(from oklch(90% 90% 0) calc(r + 1) g b)

• r -> 389.99
• calc(r + 1) ->calc(389.99 + 1)
• 390.99

The r channel is beyond the [0,255] range but there isn't any special handling in relative color syntax for this. No values are clamped or otherwise converted to "fit" within the target color space.

Having a single example that is within the p3 gamut but outside srgb would be good.

Staying within the p3 gamut is important because browsers haven't shipped gamut mapping (yet) and there is no need to complicate things further for authors.

For example :

rgb(from color(display-p3 1 0.5 0.5) calc(r - 1) g b)

• r -> 273.881
• calc(r - 1) -> calc(273.881 - 1)
• 272.881

The resulting value will be equivalent to :

• color(from rgb(from color(display-p3 1 0.5 0.5) calc(r - 1) g b) srgb r g b)
• color(srgb 1.07 0.463 0.483)

Also theoretically equivalent to rgb(272.881 117.946 123.155) but that is clamped when parsed so it isn't practically useful.

[estelle]

@chrisdavidmills I think we should add the example in #32704 (comment) to the "using relative colors" page, but definitely not to the other page. what say you?