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

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

Received on Wednesday, 25 November 2015 07:39:53 UTC