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

Thank you again @birtles for that detailed answer.

> No, you'd get a different object depending on when you called `getKeyframes()`

OK, then it is actually "the" computed value, so it's consistent in that regard. And if we do keep interpolating in specified values but compute the keyframe at `getKeyframes()`-time, I don't see a _technical_ problem with this.

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.

It would IMO even be preferable to spec that `getKeyframes()` returns an empty result if the animation is unrepresentable as a web animation vs. returning something which isn't really true.

Ideally we would change how keyframes are represented in JS if we're going for an approach that interpolates in specified value space (e.g. G-β). Otherwise, even if we did manage to stack enough special rules on top of each other to deal with all the difficulties, we'll just keep running into the problem each time CSS/the cascade/interaction-between-properties changes in the future.

Zooming out a bit again, I wonder whether G-β really is very important to the author. It seems to me that reasonable (enough) behavior both for the actual interpolation and `getKeyframes()` falls out automatically if we pick e.g. (1).

@birtles: How likely is it that we can change the (spec'd/resolved) behavior of:

 - How interpolation happens (G-β vs other options)?
 - How keyframes are represented in JS?
 - What `getKeyframes()` returns? (Not including the JS representation itself).


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

Received on Monday, 8 June 2020 09:53:45 UTC