W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2020

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

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Tue, 09 Jun 2020 04:42:45 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-641024191-1591677764-sysbot+gh@w3.org>
> However, the object we'd return seems like it has nothing to do with the actual animation. The keyframes you get don't actually represent the things we're interpolating between, but instead you get "random" keyframes depending on the current state of other interpolations. This seems not useful, and misleading. It's both losing and _adding_ information.

I think that might be overstating things a bit. The object returned represents the actual values we are interpolating between at that point. Interpolation happens in computed value space so we have to convert to computed values to interpolate and the object returned accurately represents that.

For some animations, other (typically independent) effects (e.g. from JS or other animations) may cause those interpolation endpoints to change on the next frame, but that doesn't make these values "random" any more than the values from `getComputedStyle` are "random".

To give some concrete use cases for these values (and these are literally the first two use cases that came to mind):

1. Showing a graph of the animation shape in DevTools. If an animation happened to use `em` based units _and_ `font-size` was _also_ being animated, the fact that the result of `getKeyframes()` changes on each frame would simply mean the graph may need to be re-rendered which seems reasonable. In the case where all values use `em` units, however, the graph shape would not change.

2. Polyfilling color interpolation using HSV (I really really really hope no "color space" people see this thread! 😅). In this case, we fetch the keyrames using `getKeyframes()`, synthesize a new set of keyframes, and set them using `setKeyframes()`. Obviously if one of the original keyframes used `currentcolor` and that later resolved to a different value, it would no longer be reflected in the animation (since we replaced the keyframes) but that would be true regardless of whether or not returned `currentcolor` in the first place unless the author specifically added code to watch for changes to the computed value of `color`.

In both cases, the fact we were able to get the keyframes is of great benefit as otherwise these effect would be impossible without manually fetching and cascading all the `CSSKeyframesRule` and `CSSKeyframeRule` objects ourselves.

> @birtles: How likely is it that we can change the (spec'd/resolved) behavior of:
>     * How interpolation happens (G-β vs other options)?

Given that we don't have good interop here, this seems possible depending on the scope of the change.

>     * How keyframes are represented in JS?

To the extent that these align with what we pass to `Element.animate()` which has been shipping in Chrome and Firefox for quite a while now, this seems unlikely.
>     * What `getKeyframes()` returns? (Not including the JS representation itself).

Given that this has only shipped recently, it might be possible but, depending on the scope, would probably need some use counters / telemetry to be confident we are not breaking content.

GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5125#issuecomment-641024191 using your GitHub account
Received on Tuesday, 9 June 2020 04:42:48 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:09 UTC