Re: Temporary removal of animations

2014-11-18 Thread Shane Stephens
I'm pretty sure it isn't easing - the easing string you are setting is definitely working. It might be something to do with the way you're replacing animations when adding new elements while old animations are still running? Cheers, -Shane On Wed Nov 19 2014 at 12:16:19 PM Jonathan Moore wro

Re: Temporary removal of animations

2014-11-18 Thread Jonathan Moore
The effect is most easily seen in this demo if you change the duration to be like 50 seconds: http://0x.bitbucket.org/artifact/test.html What happens is that in the web animation version you get a accordion effect where the movement of the elements is not in sync. With the raf version this

Re: Temporary removal of animations

2014-11-18 Thread Shane Stephens
Hi Jonathan, Chrome 39 implements easing. What was the problem you were seeing? Thanks, -Shane On Wed Nov 19 2014 at 11:28:26 AM Jonathan Moore wrote: > I now have a mostly working ( chome 39 ) version of my lib using web > animations. You can see a demo at: > > http://0x.bitbucket.o

Re: Temporary removal of animations

2014-11-18 Thread Jonathan Moore
I now have a mostly working ( chome 39 ) version of my lib using web animations. You can see a demo at: http://0x.bitbucket.org/artifact/index.html I think the reason it is not quite working is that it looks like chrome 39 does not yet implement easing. If that is not true I will spend more

Re: Temporary removal of animations

2014-11-18 Thread Shane Stephens
This .. also seems like a bug. currentTime doesn't progress between frames. We'll look into it. Cheers, -Shane On Wed Nov 19 2014 at 11:13:54 AM Jonathan Moore wrote: > On Tue, Nov 18, 2014 at 3:59 PM, Shane Stephens wrote: > >> >> In contrast, when the currentTime is set, this immediately

Re: Temporary removal of animations

2014-11-18 Thread Jonathan Moore
On Tue, Nov 18, 2014 at 3:59 PM, Shane Stephens wrote: > > In contrast, when the currentTime is set, this immediately resolves the > animation state to a known correct set of values. Hence no promise is > needed to delay resolution. > One thing that I thought was a little strange related to this

Re: Temporary removal of animations

2014-11-18 Thread Shane Stephens
The cancel() behavior is a bug, we're tracking it here: https://code.google.com/p/chromium/issues/detail?id=434529. Thanks for finding it! The promises have a rather specialized purpose, not related to style. The web platform already deals with the fact that style changes don't necessarily apply i

Re: Temporary removal of animations

2014-11-18 Thread Jonathan Moore
On Tue, Nov 18, 2014 at 12:39 PM, Shane Stephens wrote: > I think this issue points to a bug in the Chrome implementation. Even > though cancel is asynchronous, from the perspective of the main thread its > effect on style should be immediate (or at least appear to be - calling > cancel should in

Re: Temporary removal of animations

2014-11-18 Thread Shane Stephens
This isn't a timing issue, it's a consequence of cancel() having asynchronous effect. Inserting a new element hasn't actually updated the animation style, even though it does force a style recalc - it actually takes a rAF for the animation's effect to stop applying. I think this issue points to a

Re: Temporary removal of animations

2014-11-18 Thread Tab Atkins Jr.
On Tue, Nov 18, 2014 at 11:11 AM, Jonathan Moore wrote: > I don't think this is a browser bug. I think it is a unforchent consequence > of web animations being an async API. With all other style/layout APIs the > effects of actions are immediate. Attached is an example of the kind of > thing I do

Re: Temporary removal of animations

2014-11-18 Thread Jonathan Moore
I just came up with a hack that does what I want. If I set currentTime to a time larger than the duration it has the effect I want on the styles. I am not sure how this will affect all the promises the API specifies. On Tue, Nov 18, 2014 at 11:11 AM, Jonathan Moore wrote: > I don't think this is

Re: Temporary removal of animations

2014-11-18 Thread Jonathan Moore
I don't think this is a browser bug. I think it is a unforchent consequence of web animations being an async API. With all other style/layout APIs the effects of actions are immediate. Attached is an example of the kind of thing I do in my lib. What I would like is some way to see the effects of t

Re: Temporary removal of animations

2014-11-18 Thread Jonathan Moore
On Tue, Nov 18, 2014 at 8:43 AM, Jeremie Patonnier < jeremie.patonn...@gmail.com> wrote: > Hi! I wonder if you could just pause the animation rather than cancel it > > http://w3c.github.io/web-animations/#the-animationplayer-interface define > a pause method > > Note sure it is already implemented

Re: Temporary removal of animations

2014-11-18 Thread Tab Atkins Jr.
On Mon, Nov 17, 2014 at 5:04 PM, Jonathan Moore wrote: > A requirement of the library is that I can remove the effects of a running > animation, inspect an element's styles, and then restart the animation where > it left off. This has proven difficult with the web animation api as it is > implemen

Re: Temporary removal of animations

2014-11-18 Thread Jeremie Patonnier
Hi! I wonder if you could just pause the animation rather than cancel it http://w3c.github.io/web-animations/#the-animationplayer-interface define a pause method Note sure it is already implemented but it looks like what you are looking for: http://w3c.github.io/web-animations/#pause-a-player Be

Temporary removal of animations

2014-11-18 Thread Jonathan Moore
I am attempting to add web animation support my animation library Artifact: https://bitbucket.org/0x/artifact The approach if the library is to have the user only specify how they want to change the dom. It is then up to the library to compute a animation from the current dome state to the