Re: Temporary removal of animations

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