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