Re: [csswg-drafts] [css-animations] Resolving dependencies in keyframes (#5125)

@birtles In the interest of trying to get this issue to "converge" on _something_, let's assume that we want to continue with G-β, and that we also want to return "computed keyframes" from `getKeyframes()` (even though I still think it's weird).

But first I need to clarify the behavior:

> Interpolation happens in computed value space

Some implications of G-β + the above are (for example):

(@birtles: please review and confirm the examples).

- `em` units resolve dynamically against the computed value of `font-size`:
```
@keyframes test1 {
  from { font-size: 10px; width: 10em; }
  to { font-size: 20px; width: 20em; }
}
div {
  animation: test1 10s -5s linear paused;
}
```
At `t=0.5`, the computed value of `font-size` is `15px`. Hence the computed endpoints of the `width` interpolation are `[150px, 300px]`, and the computed value of `width` is therefore `150px + (300px - 150px) * t = 225px`.

- `var()` resolves dynamically against the computed value of the variable:
```
@keyframes test2 {
  from { --x: 10px; width: calc(10 * var(--x)); }
  to { --x: 20px; width: calc(20 * var(--x)); }
}
div {
  animation: test2 10s -5s linear paused;
}
```
At `t=0.5`, the computed value of `--x` has just flipped to ` 20px` (tokens), hence the computed endpoints for the `width` interpolation end up being `[200px, 400px]`. The computed value of `width` becomes: `200px + (400px - 200px) * t = 300px`. Note that at `t=0.4999`, the computed value of `width` instead becomes (approximately) `100px + (200px - 100px) * t = 150px`, hence the interpolation of `width` "inherits" the flip-at-50% behavior from `--x`.

- `var()` resolves dynamically against the computed value of the variable, registered property version
```
@property --x {
  syntax: "<length>";
  inherits: true;
  initial-value: 0px;
}
@keyframes test3 {
  from { --x: 10px; width: calc(10 * var(--x)); }
  to { --x: 20px; width: calc(20 * var(--x)); }
}
div {
  animation: test3 10s -5s linear paused;
}
```
This is the basically the same thing as `test1`, and the computed value of `width` becomes `225px`.

 - Dependencies resolve against the actual computed value of the dependency:
```
@keyframes test4 {
  from { font-size: 10px; width: 10em; }
  to { font-size: 20px; width: 20em; }
}
div {
  font-size: 30px !important;
  animation: test4 10s -5s linear paused;
}
```
The interpolated `font-size` is not relevant for `em` resolution here, hence the computed value of `width` is `300px + (600px - 300px) * t = 450px`.

What I think we should do now:

 - Spec the G-β behavior more clearly (I can try). I think it's worthwhile to mention the `em`/`font-size` case, some custom props cases, and possibly a case with transitions, or something else that makes it clear "which" computed value is used for dependency resolution.
 - Spec that the UA must behave as if computed keyframes are produced dynamically immediately before interpolation.
 - Spec that specified values are retained internally, but `getKeyframes()` outputs the computed keyframes. (There's a lot of confusion about "when" keyframes are computed at the moment).
 - Add WPTs for difficult cases (I can contribute), reviewed by @birtles. Or investigate if they already exist.

Another possible other way of explaining it is that the animation `test1` adds values to the cascade at the animations level equivalent to:

```
font-size: interpolate(10px, 20px, 0.5);
width: interpolate(10em, 20em, 0.5);
```
Where the params are resolved to absolute values before interpolation occurs.

When it comes to `getKeyframes()`, is there still any open issue re. "ambiguous clobbering" of properties? Since we absolutize all values in the computed keyframes, there should be no difficult cases with custom properties, since no `var()` references are present? (You tried to explain this in comment 4, but I can't tell whether or not there's still an issue). I don't immediately see any remaining issues, even if we include custom properties in the result of `getKeyframes()` (which we should, #5126).


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

Received on Thursday, 11 June 2020 10:27:57 UTC