Hi,
We have a difficulty in Web Animations with regards to object lifetimes
for animations that fill forwards. The trouble is one can do the
following:
elem.addEventListener('click', evt => {
evt.target.animate({ opacity: [ 0, 1 ] },
{ duration: 500, fill: 'forwards' });
});
What this does, is create a new animation that fills forwards, on every
click.
Now, if we call:
elem.getAnimations();
It should return *all* the animations we've generated.
There are few reasons for that:
a. You should be able to use getAnimations() to help answer the
question, "Why does my element have this style value?"
i.e. This method needs to return any animation that is affecting
the element in question.
b. Animations can add together so you need to keep track of all the
past animations anyway so you get the right final result.
e.g. you can do the following
// Nudge right
elem.addEventListener('click', evt => {
evt.target.animate({ transform: 'translate(50px)',
composite: 'add' },
{ duration: 500, fill: 'forwards' });
});
The total distance the element is translated is the sum of the fill
values of all animations that have run up to that point.
All that means you really need to keep track of all the forwards-filling
animations. Forever.
Why is this a new problem?
For CSS transitions and CSS animations, once animations are no longer
referenced by specified style they are cancelled and no longer affect
the element.
You just don't accidentally end up in a situation with millions of old
animations lying around. To do that, you'd have to have a *lot* of
elements or have an animation-name value that is very long. Either
case tells you to expect things to go slowly and are somewhat bounded.
With the animation API, however, as shown in the examples above, it's
quite easy to get into a situation where the UA has to keep a lot of
Animations around without the author realizing it.
Solutions we've discussed until now:
a. Automatically cancel any filling animation when other filling
animations cover the same properties.
=> Doesn't work for addition.
b. Make getAnimations() only return the *last* animation that is
filling per-property.
=> For the addition case, you'd still need to keep around some
sort of summary of the result of previous animations. Now,
supposing you don't expose that summary, the view you see from
the API is inconsistent.
c. Expose the summary view of underlying filling animations as
some sort of special animation or a special attribute.
=> This is awkward, but maybe worth revisiting?
e.g. elem.getFillStyle().opacity?
d. "That's the author's problem" or "Just let UAs just do whatever
they feel like"
=> This is our current position and it's not great.
I really think we need to fix this. I don't have any brilliant ideas.
Revisiting (c) could work, or perhaps some sort of "animation collapsing"?
The rough idea of "animation collapsing" is that when the UA has two or
more filling animations on the same properties on the same element, it
basically takes the fill values of the underlying animations and
squashes them into the property values specified on the top-most
filling animation. Then the underlying animation ends becoming empty
and can be discarded.
(I'd really like to make it so that the underlying animation actually
gets cancelled and you get an event for it, but I think when it comes to
group effects, you want to be able to collapse individual effects
without having to have a complete match for all effects.)
Adding a bit more details I think it could be something like:
Assume:
* all finished animations do NOT fill forwards have been discarded
* Element.getAnimations() does not return Animations targetting
Element if the set of keyframes is empty
For any two effects, A and B, (with corresponding animations, 'Animation
A', and 'Animation B') where:
a. A and B have the same non-null target element
b. Animation A and Animation B are both finished
c. Animation A and Animation B each have a fill mode of either
'forwards' or 'both'
d. Animation A and Animation B have the same animation type
e. The common animation type of Animation A and Animation B allows
collapsing (disallow for CSS animations/transitions)
f. For each animation property that is common to both A and B, there
is no animation effect referring to that animation property whose
corresponding animation has a composite order between that of A
and B.
Perform the following steps:
1. Assume that A refers to the effect whose corresponding animation
has a *lower* composite order of the two.
2. For each animation property, |property|, that is referenced by both
A and B, update each specified value |property| on B as follows:
i. Let |b| be the specified value of |property| on a keyframe in
B.
ii. Let |a| be the fill value of |property| on a keyframe in A.
iii. If the composite mode associated with |b| is 'replace',
let b' = |b| and composite' = 'replace'.
Otherwise, if the composite mode associated with |b| is 'add',
let b' = add(|a|, b) and composite' = the composite mode of
|a|.
Otherwise, (the composite mode associated with |b| is
'acccumulate),
let b' = accumulate(|a|, b) and composite' = the composite
mode of |a|.
iv. Update |b| with b' and use composite' as the composite mode
for the keyframe.
(TODO: Add logic here to handle when we have multiple
properties on the same keyframe and we are changing the
composite mode. Basically, make a new keyframe in that case,
but then combine such keyframes at the end of the process.)
3. Remove all values of |property| on keyframes in A.
4. Remove any empty keyframes on A.
It's pretty complicated and I don't love it, but I think it's a little
closer to the pit of success we'd like to create? If nothing else, it
might spark a better idea from someone else.
Best regards,
Brian
