- From: Chris Marrin <cmarrin@apple.com>
- Date: Mon, 28 Mar 2011 11:45:49 -0700
- To: Simon Fraser <simon.fraser@apple.com>
- Cc: Rik Cabanier <cabanier@gmail.com>, Dean Jackson <dino@apple.com>, Paul Bakaus <pbakaus@zynga.com>, "public-fx@w3.org" <public-fx@w3.org>, www-style list <www-style@w3.org>
On Mar 28, 2011, at 11:13 AM, Simon Fraser wrote: > I think the approach of trying to set up the next animation from JS at the end of a previous animation is wrong. The browser will never be able to seamlessly stitch the two animations together in that case, since the events are necessarily asynchronous (to avoid re-entrancy issues). This is especially true when the browser is actually running the animations off in another thread, as Safari does with some animations. > > A better approach would be to design an API for controlling animations. The author could then use this to queue the next animation before the end of the previous one. Queue? If you mean a real queue, then I think that can be done declaratively, too, right? The nice thing about the WebKit implementation at least, is that once the animation starts you know exactly when it will end. So queuing up events that trigger when a precise time point is reached should be pretty easy, either declaratively or programmatically. ----- ~Chris cmarrin@apple.com
Received on Monday, 28 March 2011 18:47:54 UTC