Re: Temporary removal of animations

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 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 invalidate the style of the element the animation is
targeting). After all, the animation itself is observable as cancelled -
its playState switches immediately to 'idle'. I'd like to talk it over with
some people on my team but assuming they agree I'll file a bug on our impl.

Cheers,
    -Shane



On Wed Nov 19 2014 at 6:34:00 AM Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> On Tue, Nov 18, 2014 at 11:11 AM, Jonathan Moore <moore@eds.org> 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 in my lib. What I would like is some way to see the effects of
> > the cancel() immediately; or better yet a way to ask for the computed
> style
> > ignoring the animations effects ( without interrupting the animation ).
>
> Thanks for the example!  Yes, that confirms that it's a timing issue;
> the effects of stopping the animation haven't yet been recalculated
> when you first ask for the data.  Adding a new element forces a style
> recalc, as the browser needs to figure out what styles apply to that
> element.
>
> There are other ways to force style recalcs; this sort of issue is
> unfortunately common on the web, and you should be able to find plenty
> of tutorials for it.
>
> ~TJ
>
>