[web-animations-1] Define requirements for retaining animations to be returned by getAnimations

[birtles]

From @birtles on September 30, 2015 4:50

https://w3c.github.io/web-animations/#issue-8748c168

Copied from original issue: w3c/web-animations#118

[birtles]

Depending on how we solve this, this might involve adding a whole new FillAnimation interface.

[birtles]

We've discussed this issue a number of times in the past. Every time we assume there's some quite simple answer and yet we always seem to converge on the following approach.

Requirements:

• For forwards-filling animations there should be some way to see what value is being applied by animation, e.g. for DevTools etc. to explain why the element has the style it does.
• It should be possible to cancel the styles applied by forwards-filling animations. You shouldn't be able to get into a state where you can't clear animation styles (e.g. because you accidentally dropped all the Animation handles).
• UAs should be able to use a compact representation for forwards-filling animations--i.e. they should not be required to retain the original Animation object of every forwards-filling animation.
• Handles to existing Animation objects should continue to be valid, even once the Animation starts filling-forward. i.e. we shouldn't introduce a situation where an Animation is completely functional (can be canceled etc.) but becomes suddenly neutered simply by the passing of time.
• The UA's garbage collection should not be observable.

Desirable qualities:

• Uses the same APIs as far as possible to reduce API surface area and allow generic handling of playing and forwards-filling animations (e.g. cancel all animations, get the effect of all animations)

Approach:

• Introduce a new FillAnimation subclass of Animation.
• All setters on FillAnimation throw (or alternative create an AnimationReadOnly superclass)?
• All playback methods on FillAnimation throw except cancel().
• fillAnimation.effect.updateTiming() also throws. (Or coin a new effect for this?)
• FillAnimation represents 1 or more forwards-filling animation
• fillAnimation.effect.getKeyframes() returns the set of keyframe values being filled. (Do we just specify the 100% keyframe and using timing of duration: 0; fill: both?). It may need multiple keyframes if the individual properties have different composite modes.
• getAnimations() coalesces as many forwards-filling properties as possible into each FillAnimation.
• The object identity of each FillAnimation changes only when the set of underlying animations it represents changes. (Not sure if this requirement is necessary.)
• Handles to Animations that are filling forwards and therefore represented by a FillAnimation are still usable. Canceling such an Animation would cause a new FillAnimation to be generated.
• Canceling a FillAnimation will cause any Animation objects it represents to be canceled.

[birtles]

Considering a fairly complex example. Suppose we have:

A. Forwards filling: opacity
B. Forwards filling: opacity (composite: add), transform (composite: add)
C. Playing: transform
D. Forwards filling: transform
E. Forwards filling: background-color
F. Forwards filling: background-color (composite: add)
G. Forwards filling: background-color (composite: add)

Script has a handle to F.

getAnimations() in this case will return:

1. FillAnimation representing A and B (with two keyframes -- the opacity keyframe has composite: replace and the transform keyframe has composite: add)
2. Animation C
3. FillAnimation representing D~G (with one keyframe containing transform and background-color with composite: replace).

Internally, (3) needs to represent D+E, F, G since there is still a handle to F and script could call cancel() or even play() on F in which case the visual result will change and the result of getAnimations() would change.

Once script drops all references to F, the UA can collapse to the result of D+E+F+G internally. This is not observable, however.

This behavior can nest in that script could take a reference to the FillAnimation in (3) and then if C finishes and fills forwards getAnimations() would return a new single FillAnimation that internally recognizes that the FillAnimation from (3) is still alive and allows that FillAnimation to be independently canceled.

[birtles]

This issue is likely to be covered by #3210 for which there is an in-progress patch.

[birtles]

Closed by db06d5f.