[css-animations] Add control of colorspace used for animating colors

[svgeesus]

( Spun out from #7035 )

Currently, all animation of color happens in gamma-encoded sRGB space. There is a need to preserve this as a default, for Web compat. However, CSS Color 4 defines a bunch of other color models, which exceed the very limited gamut of sRGB, and there is a need to add control of the color space used for interpolation which is currently unspecified:

• to avoid needless conversion to sRGB, dropping the more saturated colors
• because interpolating in gamma-encoded space gives overly dark midpoint colors
• because some color spaces give better results than others, which kind of varies depending what the start and end colors are, so stylesheet authors need the flexibility to choose.

As this is a common requirement, CSS Color 4 defines a <color-interpolation-method> token and associated color interpolation math; this has already been used in the grammar for `color-mix() in CSS Color 5 and in linear, radial and conic gradients in CSS Images 4.

So this issue proposes to add a new property, initial value auto:

animation-interpolation: [ auto | <color-interpolation-method> ]#

and also to add this to the animation shorthand. There is no ambiguity (unlike time) so it can go in any order in the shorthand.

[birtles]

Is there a need to interpolate in a different colorspace per transition/animation? Or would it be acceptable to say that all animations/transitions on an element always use the same colorspace?

If it's the former, then this will need to be defined at the Web Animations level and mapped to corresponding properties in CSS animations/transitions.

If it's the latter, then perhaps we could use a generic property similar to SVG's color-interpolation-filters and apply the computed value of that property to any animations/transitions of color values on that element.

There is no ambiguity (unlike time) so it can go in any order in the shorthand.

I'm afraid this still hits the issue where we can't easily add new keywords to the animation shorthand as discussed in #6946. For what it's worth, the latter approach of using a generic property covering all animations would avoid this.

[svgeesus]

Is there a need to interpolate in a different colorspace per transition/animation?

Yes. For maximal Web compat, existing animations need to continue to animate in gamma-encodes sRGB space; yet animations using other, wider gamut color spaces would be severely hampered by being forced to do so.

Also, stylesheet authors may choose to use different colorspaces on different animations or transitions depending on the effect they want to achieve.

I'm afraid this still hits the issue where we can't easily add new keywords to the animation shorthand as discussed in #6946.

So, this means that authors would need to use the animation shorthand to set most of the animation, then a longhand to set the animation colorspace?

If it's the former, then this will need to be defined at the Web Animations level and mapped to corresponding properties in CSS animations/transitions.

Could you unpack that a bit more for me, so I have a clearer idea of what to do next?

[birtles]

Is there a need to interpolate in a different colorspace per transition/animation?

Yes. For maximal Web compat, existing animations need to continue to animate in gamma-encodes sRGB space; yet animations using other, wider gamut color spaces would be severely hampered by being forced to do so.

I don't quite follow the Web compat angle. I assumed this property was acting as an opt-in to use a different colorspace for interpolation for the element(s) it is applied to?

Then again, I think my question was poor. I'm curious if, for a given element, there is a need to apply a different colorspace for different animations/transitions.

Also, stylesheet authors may choose to use different colorspaces on different animations or transitions depending on the effect they want to achieve.

I can see that would give more flexibility, I'm just wondering if in practice it's needed since it might be simpler if it's not (that is, if authors only ever need to specify one interpolation colorspace per element). But perhaps the Web compat aspect makes this point moot.

I'm afraid this still hits the issue where we can't easily add new keywords to the animation shorthand as discussed in #6946.

So, this means that authors would need to use the animation shorthand to set most of the animation, then a longhand to set the animation colorspace?

Yes, either that or we find a way to somehow add keywords to the animation shorthand. We face this same issue with the animation-composition property and if we ever introduce new easing keywords we will face it there too so it would be nice to find a general solution to this problem.

If it's the former, then this will need to be defined at the Web Animations level and mapped to corresponding properties in CSS animations/transitions.

Could you unpack that a bit more for me, so I have a clearer idea of what to do next?

I think we'll need to determine first:

• Do we want to allow the author to vary the interpolation colorspace between keyframes like animation-timing-function allows? (i.e. use one colorspace between keyframes A and B, but use another between B and C?)
• Or is it enough for the interpolation colorspace to apply across all keyframes in the animation?

If it's the former, we'll want to add a special property like we already have for offset, easing, and composite (e.g. in this procedure).

If it's the latter, then I imagine we'll extend the definition of keyframe effects, perhaps with a section on "interpolation parameters" or the like defining an "interpolation colorspace" parameter or such in the model along with its default value. Then we'd add a suitable IDL member to KeyframeEffect and KeyframeEffectOptions similar to composite and define how it is applied by the KeyframeEffect constructor.

In either case, then we'd finally need to indicate the mapping between the CSS property and the Web Animations model concept in CSS Animations 2 / CSS Transitions 2 (e.g. the mapping for animation-duration).

For the former case where we allow different colorspaces per interpolation interval, we'd also need to add some prose explaining how to build up the keyframes for a CSS animation in this section.

[LeaVerou]

I think we should close this and frame the discussion in #7063 (which has received more discussion — 16 vs 3 comments) around both transitions and animations the solution should be the same in both. What do you think @svgeesus?

[svgeesus]

I agree that we want to have the same solution for animations and for transitions, so closing this in favor of #7063 makes sense.