[css-color][css-animations] Is it specified anywhere that a color animation at time=0 exactly match the from color's computed value?

[weinig]

In the WPT test http://wpt.live/css/css-animations/animate-with-background-color-oklch-002.html, the first subtest is testing an animation from background: #ff0000 to background-color: oklch(45% 0.2 264) at a few different time steps as described by this list:

  const bg_color_legacy_rgb_to_oklch = [
    { at: 0, value: 'rgb(255, 0, 0)' },
    { at: 0.25, value: 'oklab(0.583475 0.163433 0.0446685)' },
    { at: 0.5, value: 'oklab(0.538983 0.101987 -0.0365225)' },
    { at: 0.75, value: 'oklab(0.494492 0.0405407 -0.117713)' },
    { at: 1, value: 'oklab(0.45 -0.0209057 -0.198904)' }
  ];

Generally, when computing the value of a color animation at a particular time step, it is going to have a computed value that is serialized as OkLab color, since that is the interpolation color space.

This test however, assumes that at time=0, the computed value should be precise value of the from color, which has a computed value using the legacy RGB serialization.

Is this behavior, of acting like no interpolation happed at all, specified anywhere?

(cc @birtles, @dbaron, @graouts, @svgeesus).

[jfkthame]

I don't think this is specific to time=0; in a little local testing with Chrome, it also seems to happen at other times that exactly match one of the specified color-stops in the animation.

[weinig]

Yeah, I kinda knew it was broader, but struggled to find a succinct way to ask the question for the general case.

[svgeesus]

It seems like in the general case, the animations spec should be clear whether you get the specified or computed value

• when it has to be computed because it isn't one of the stops
• when it exactly matches a stop (it could still return the computed value, of course, if the spec says so)

@birtles ?

[birtles]

Is this behavior, of acting like no interpolation happed at all, specified anywhere?

Yes, it falls out of the interpolation procedure which has:

Given two property values VA and VB, produces an intermediate value Vresult at a distance of p along the interval between VA and VB such that p = 0 produces VA and p = 1 produces VB.

It seems like in the general case, the animations spec should be clear whether you get the specified or computed value

• when it has to be computed because it isn't one of the stops
• when it exactly matches a stop (it could still return the computed value, of course, if the spec says so)

It always uses computed values as per https://drafts.csswg.org/web-animations-1/#calculating-computed-keyframes specifically where it has:

Compute a property value using the value specified on keyframe as the value, and the target element as the element; then add the property and resulting value to computed keyframe.

It's just that rgb(255, 0, 0) is a computed value, but it's never interpolated with anything because it's at the endpoint of the interpolation interval.

[Loirooriol]

Yeah this is not specific of colors at all, e.g. animating font-style: normal to oblique 50deg is like

• At 0%, normal (not oblique 0deg!)
• At 1%, oblique 0.5deg
• At 50%, oblique 25deg
• At 100%, oblique 50deg

[svgeesus]

• At 0%, normal (not oblique 0deg!)

Is it though?

• [css-fonts] Should font-style: oblique 0deg serialize as font-style: normal? #11430
• [css-fonts] Should font-style: oblique 0deg serialize as oblique 0deg or normal? #10911

[weinig]

Is this behavior, of acting like no interpolation happed at all, specified anywhere?
Yes, it falls out of the interpolation procedure which has:

Given two property values VA and VB, produces an intermediate value Vresult at a distance of p along the interval between VA and VB such that p = 0 produces VA and p = 1 produces VB.

@birtles Thanks! Ok, I can totally see how that would mean that at time=0, and time=1 should return the identical serialization, since it calls out "p = 0 produces VA and p = 1 produces VB". Great!

What about at other explicit stops. For example, what would you expect the computed value serialization be for the following:

  @keyframes bg-color-legacy-rgb {
    from {
      background-color: red;
    }
    50% {
      background-color: lime;
    }
    to {
      background-color: blue;
    }
  }

Not sure where in the spec the interpolation procedure is invoked, so I can't tell if the interval (p=0 to p=1) is exactly time=0, to time=1, or if it is percentage of the current keyframe (I kinda assume animations would invoke it per-keyframe).

So (and I will make a new WPT test with these answers), what should the computed value serialization be for that animation above at various timesteps:

I think I know these first three:

• At time=0, we are saying the computed style serialization would be rgb(255, 0, 0).
• At time=1, we are saying the computed style serialization would be rgb(0, 0, 255).
• At time=0.25 (or any non-explicit stop), we are saying the computed style serialization would be some oklab() value.

But what about time=0.5? Should it be rgb(0, 255, 0) or oklab(87% -0.23 0.18)?

[birtles]

Sorry, away from my computer for a bit but the interpolation behavior applies to any interpolation interval and the process of computing a keyframe's effect value will set up an interpolation interval between the closest keyframes so not necessarily time=0/1.