Re: Temporary removal of animations

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

On Tue, Nov 18, 2014 at 10:08 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> On Mon, Nov 17, 2014 at 5:04 PM, Jonathan Moore <moore@eds.org> 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
> > implemented in chrome 39. Do do so I have to save the player.currentTime,
> > cancel the animation, and restart it and set currentTime. This is ok but
> > does not work reliably sometimes things like
> element.getBoundingClientRect(
> > ) don't reflect the changes due to canceling the animation.
>
> It sounds like you're running into timing issues with style recalc;
> the styling queue hasn't been fully flushed by the time you measure
> the size of the element, so you're getting stale information.
> Unfortunately, style recalc has never been really specified (finding a
> way to spec it that doesn't limit browser optimizations is hard), so
> getting around this is tricky.  Typically, asking for something that
> requires accurate information, like .offsetTop, will trigger a full
> style recalc.
>
> If you're doing something like this, and *still* receiving inaccurate
> information, it's likely a browser bug.  If you can reduce the problem
> to a very simple example (preferably with only a few lines of code;
> not your entire library operating), it should be easy to isolate and
> hopefully to fix.
>
> ~TJ
>