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 <[email protected]> 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 ). > > On Tue, Nov 18, 2014 at 10:08 AM, Tab Atkins Jr. <[email protected]> > wrote: > >> On Mon, Nov 17, 2014 at 5:04 PM, Jonathan Moore <[email protected]> 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 >> > >
