W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2015

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

From: Brian Birtles <bbirtles@mozilla.com>
Date: Wed, 25 Nov 2015 16:38:34 +0900
To: Kevin Doughty <socallednonflipped@gmail.com>, public-fx@w3.org
Message-ID: <5655657A.4030109@mozilla.com>
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 

* 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,

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:54 UTC