Re: [web-animations] Freeing up forwards-filling Animation objects

I failed to mention another Core Animation property that relates to your
stated issues, but I’ve written about it on the public-fx list before, more
than two years ago. Animations have a property, “removedOnCompletion” which
might seem redundant with fillModes. It determines if animation instances
are automatically removed. This differs from fillModes which determine if
animation effects persist or are removed.


> Even if we decide to only return animations that have an id, I think
we'll still have a few issues:

>

> * We still need to preserve historical data … Forcing DevTools to go and
annotate the animations with ids in order to be able to fetch them seems
unfortunate but not impossible.

>

> * Other applications that also want to preserve the ability to replay
animations will probably wrap elem.animate() to always add an id


There should be a method to getAnimations, regardless if they are named or
not. I think it’s great that UAs will be using the same public API for
DevTools. I agree DevTools should definitely not be assigning keys if the
user doesn’t. In CA, a getAnimations (whether keyed or not) is notably
absent. If you don’t name them and they forward fill (actually if not
removedOnCompletion) then one must use removeAllAnimations which would kill
named and non-named alike. Names should be for the developer to
individually recall them and distinguish them, and to easily replace one
animation with another like CSS Transition behavior.


> * You'll no longer be able to answer the question, "Why is my element
over there?" by inspecting all the animations that are applying to the
element.


If it’s too confusing then developers should choose not to use a forward
fill. I don’t recommend it most of the time although for simple use cases
it’s fine, especially if named. But otherwise it is better to assign
property values or layout using the tools originally designed to do so.


> * Making the object returned from elem.animate() non-live seems like a
significant usability regression.


Actually, I was suggesting that elem.animate() not return anything at all.
The current return value is a vestige of players, which are renamed
animations now, I think. With the interface I want it’s just not needed.
Speaking of players, CA has an entirely different timing model. Both
elements and animations have timing. CA lacks play and pause, and to
accomplish this I admit it is pretty awkward having to set speed to zero
then resume by calculating time offset. But it has the advantage of a
nested time hierarchy. Changing speed on a container element changes speed
of all animations on all sub elements. Without this, developers would have
to pause every single animation one at a time.


> At this stage the best options I can think of are:

>

> 1. Define a process whereby UAs can flatten historical data at a point
where the UA decides it is necessary. … but the older animations would
simply not run (e.g. on desktop the UA might decide, based on current
memory pressure …


How do UAs handle the case where a dev maliciously or unintentionally
creates non-animation objects that never garbage collect? It should also be
possible to create disastrous effects by playing many animations with a
very long duration. I don’t get why this isn’t a problem too..


> 2. Define getAnimations() so that it doesn't return filling animations.
Let UAs represent forwards-filling animations however they like so long as
they preserve animations to which script is maintaining a reference.


Forward filling animations can be created in CSS, thus devs wouldn’t have
access to them. Arbitrary decisions like this could make an API difficult
to understand. Also, cross-cutting concerns of tracking references in
scripts to handle animation can’t possibly be a good idea. Maybe this is a
more common technique in javascript, with garbage collection, that I am
unaware of.


Going back to the original message in this thread which I did not address
because I was too busy advocating Core Animation:


>   a. Automatically cancel any filling animation when other filling
animations cover the same properties. => Doesn't work for addition.


This is how to-animations work, isn’t it? Are they no longer part of
Web-Animations or has the behavior changed? There is no point to use
additive & a forward fill, assuming a forward time direction, but depending
on the effect of delay which I’m not sure about, a backwards fill might be
useful. There might be a use for forwards but it would be pretty obscure
compared to to-animations and replacing animations. Values would
accumulate. If you decline to use names then why not go back to the
interface that naturally created the state we’re in now? Only one forward
filling animation. All others get invalidated.


> 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


Maybe it would be better to use fills as a replacement for keys and be
honest with getAnimations actually returning all animations.
Merging/combining the results of forward filling additive animations if
they have entered their fill phase would get confusing when people start
removing animations. Can you ban additive animations from filling at all? I
do not like arbitrary decisions like this but am at a loss. You also
probably know I do not like deviation from Core Animation behavior. I
prefer animation names and to let forward fills accumulate forever if the
dev is careless.


Ban additive fills or ban additive altogether. Since you’ve declined to
provide a way to convert from absolute to relative values, frankly there is
little use for additive. Relative transitions are impossible. All that
remains are counter-intuitive manual calculations for explicit animation.
You could keep to-animations and develop a mutable spring physics like
Rebound/POP for level 2. Dropping additive would lose multiple animations
running concurrently, blending of easing, and blending keyframe animations.
Of course I wouldn’t like it but that doesn’t matter, does it?


Blend modes like “absolute”, “relative”, “to-animations” (or whatever you
want to call it, maybe “smoothing” or “dampening”) is something that I’ve
suggested before. But that was a lost cause a long time ago.

On Wed, Nov 25, 2015 at 2:38 AM, Brian Birtles <bbirtles@mozilla.com> wrote:

> Hi Kevin,
>
> Thanks for your mail.
>
> On 2015/11/25 13:52, Kevin Doughty wrote:
>
>> element.animate(animation [, name]);
>>
>> element.animate(effect, timing [, name]);
>>
>>
>> This would permit usage patterns that avoid your stated problems
>>
>
> I'm not really sure that adding optional names is going to solve this. We
> already have an id member on the KeyframeAnimationOptions for this and we
> already have plans to allow getting animations by name (I'll follow up with
> a separate mail related to this).
>
> Even if we decide to only return animations that have an id, I think we'll
> still have a few issues:
>
> * We still need to preserve historical data if we want to replay
> animations. The DevTools in both Firefox and Chrome do this and authors
> love it. Forcing DevTools to go and annotate the animations with ids in
> order to be able to fetch them seems unfortunate but not impossible.
>
> * Other applications that also want to preserve the ability to replay
> animations will probably wrap elem.animate() to always add an id and then
> we're back where we started.
>
> * You'll no longer be able to answer the question, "Why is my element over
> there?" by inspecting all the animations that are applying to the element.
>
> * Making the object returned from elem.animate() non-live seems like a
> significant usability regression.
>
>
> At this stage the best options I can think of are:
>
> 1. Define a process whereby UAs can flatten historical data at a point
> where the UA decides it is necessary. Then you'd get full fidelity replay
> up to a point the UA decided after which the more recent animations would
> continue to behave as expected with regards to their additive behavior, but
> the older animations would simply not run (e.g. on desktop the UA might
> decide, based on current memory pressure, that the threshold before
> flattening starts is 100 script-generated forwards-filling animations).
>
> 2. Define getAnimations() so that it doesn't return filling animations.
> Let UAs represent forwards-filling animations however they like so long as
> they preserve animations to which script is maintaining a reference. Then
> if authors want to interact with such animations (including replaying
> them), they need to keep a reference to them. This means, of course, that
> you can't answer the question, "Why is my element over there?" unless you
> track every single animation.
>
> There might even be some combination of the two where we say that we don't
> flatten animations which script is referring to. That way authors have a
> way of preserving animations in-tact.
>
>
> Best regards,
>
> Brian
>