[css-color-4] When do color space conversions happen?

[frivoal]

Maybe I missed something, but as far as I can tell css-color-4 is silent about whether converting colors expressed in different profiles/spaces (using color(), lab(), lch(), or gray()) to the working color space is something that happens at computed value time, used value time, or some other time, and how that affects serialization.

Given that for color properties, the resolved value returned by getComputedStyle() is the used value, the serialization should be the same if the conversion happens at computed or used value time: the converted value. However, when the working color space is (for instance) sRGB, if we expect color(rec2020 0 255 127) to serialize as color(rec2020 0 255 127) rather than as rgb( x, y, z) (or color(srgb x y z)) then supposedly, the conversion must happen after used value time.

On the other hand, if the conversion is handled after computed value time, presumably this means we cannot animate from color(foo 1 2 3) to color(bar 4 5 6).

I think that being able to animate between all sorts of colors is more valuable than a more literal serialization (and we already do all sorts of changes to the computed value anyway), so I'd lead towards doing the conversion at computed value time.

I'm guessing this is the intent of the spec already, but I have not found a clear statement one way or the other.

[svgeesus]

You are correct, it needs to be described and it does affect serialization. This will go in the section on working colorspace, which has yet to be written.

[svgeesus]

On the other hand, if the conversion is handled after computed value time, presumably this means we cannot animate from color(foo 1 2 3) to color(bar 4 5 6).

No, that doesn't follow.

[frivoal]

On the other hand, if the conversion is handled after computed value time, presumably this means we cannot animate from color(foo 1 2 3) to color(bar 4 5 6).

No, that doesn't follow.

As I understand, animations and transitions work on computed values. If the computed value is not in the same color space, how can you animate? what is 25% of the way between color(foo 0 0 0) to color(bar 0 0 100)? 25% of the way between 0 and 100 is 25, but 25% of the way between foo and bar is what?

[grorg]

I think the transitioning question should be separate #883

[svgeesus]

As I understand, animations and transitions work on computed values. If the computed value is not in the same color space, how can you animate?

By converting them to the working colorspace first. Since this is a new concept for CSS the default value of the working colorspace is sRGB (for backwards compat) which will result in clipping. Picking a more suitable working colorspace avoids that. Interpolation happens in the working colorspace.

[svgeesus]

Maybe I missed something, but as far as I can tell css-color-4 is silent about whether converting colors expressed in different profiles/spaces (using color(), lab(), lch(), or gray()) to the working color space is something that happens at computed value time, used value time, or some other time, and how that affects serialization.

I realize that this issue has lain dormant for a while, so some updates:

• The section on resolving <color> values (started by @frivoal ) has been fleshed out.
• A new section on serializing <color> values expands what CSSOM used to say from sRGB-only to all the color formats. Colors in color() are kept as specified. lab() and lch() serialize as lab, and gray() was removed per WG discussion.
• CSS Color 5, which is about mixing and modifying colors has a section on color interpolation which states that if two colors to be interpolated are in the same space, they interpolate in that space (this gives us legacy compat for sRGB values); that colors in different spaces are converted to lab for interpolation, and that individual properties or functions may override that (for example color-mix() overrides the space to LCH by default and allows any other space to be explicitly specified.

Not all the places which carry out color interpolation have been ungraded to point to Color 5 or to define whether they allow overriding to another space; I'm getting to them one by one.

This per-property or per-function definition is more flexible than a single per-document or per-element working colorspace. Some operations (like compositing) are best done in a linear-light space like XYZ or a linearised RGB space; some like transitions, gradients, animations are best done in Lab so that the intermediate values are perceptually evenly spaced.

If the computed value is not in the same color space, how can you animate? what is 25% of the way between color(foo 0 0 0) to color(bar 0 0 100)? 25% of the way between 0 and 100 is 25, but 25% of the way between foo and bar is what?

When they are interpolated, the first color is converted to L1 a1 b1 and the second to L2 a2 b2 and those components are linearly interpolated to give the 25% value. If they are not fully opaque, Color 5 also defines interpolating with alpha

[svgeesus]

@frivoal does that answer your question regarding when color space conversions happen? In general they don't happen until a particular operation needs them (compositing, gradients, animations, transitions, color-mix). In particular, setting then serializing and individual value does not trigger colorspace conversion.

[svgeesus]

@frivoal please re-open if not satisfied