Bug 43023 – CSS Animations: Restarting animations without a setTimeout doesn't work

• Status: VERIFIED
• Resolution: REMIND
• Component: CSS

[Paul Bakaus]

Hi,

it seems that this bug is so apparent that Apple's own guidelines have to workaround it, as they're all using setTimeout to restart an animation. This is actually pretty severe, as there's currently no way to animate smoothly from one keyframe based animation to another.

I'm having this specific issue as I'm animating walking characters in an isometric path (in eight directions). So the animation goes into one direction for one tile (say, 45px), and then the animation needs to be restarted due to the nature of the tiling. With setTimeout and plenty of characters, you'll see noticable pauses, as the setTimeout is only executed after the current action queue is done.

If there's already another workaround for this, please let me know and I'll be quiet :)

[Simon Fraser (smfr)]

This isn't a problem specific to animations. It's a result of the way that browsers batch style changes.

One workaround is to use offsetWidth to force the engine to to do a style resolution/layout.

This bug has no testcase and does not describe a specific issue, so closing.

[Paul Bakaus]

Excuse me, how is this not a specific issue? It is such an apparent issue that even Apple is recognizing it. And yes, there is a testcase attached in the URL specified, which is best showing the significance when Apple itself needs workarounds.

Thanks for the information that this is related to style change batching. This doesn't make it any better though. Might need to change a category or open another ticket. If you give me instructions about the right category, I'll go right ahead.

[Paul Bakaus]

Bump. This is a real issue.

[Dean Jackson]

I think https://bugs.webkit.org/show_bug.cgi?id=54151 might cover this. We need to flesh out the API a little more, but it would be something like:

var a = myElement.webkitGetAnimation()[0];
a.pause();
a.elapsedTime = 0;
a.play();

[Paul Bakaus]

(In reply to comment #4)
> I think https://bugs.webkit.org/show_bug.cgi?id=54151 might cover this. We need to flesh out the API a little more, but it would be something like:
> 
> var a = myElement.webkitGetAnimation()[0];
> a.pause();
> a.elapsedTime = 0;
> a.play();

This looks pretty cool. Thank god you guys show us a little JS API love :) Looking forward to seeing the API stabilize.

[Rik Cabanier]

(In reply to comment #4)
> I think https://bugs.webkit.org/show_bug.cgi?id=54151 might cover this. We need to flesh out the API a little more, but it would be something like:
> 
> var a = myElement.webkitGetAnimation()[0];
> a.pause();
> a.elapsedTime = 0;
> a.play();

I don't believe this will solve the problem since the event will fire asynchronously. Because of this, it will be too late by the time the JS code is executed.

[Dean Jackson]

Correct. You simply cannot rely on DOM events for accurate timing (whether in animations or not).

But the bug was about restarting an animation within the same JS cycle (so that you can avoid setTimeout). The code above would do that.