This is awesome! It (almost 😄) works! 🎉

"Almost" works since rotation doesn't seem to work anymore, probably we'll need to add another wrapper for the animations so that it wouldn't collide with the rotation wrapper.

One additional comment from functional testing:
In some animation cases, for example in case of Fly In Bottom, the resizing handles are visible while the animation is happening, could we remove those for the animation time?

Rotation issue:

Resizing handles issue:

I'm actually seeing odd behavior for resizing as well, didn't happen on develop, could you confirm if you see the same? (Resizing from one edge seems to move the block from other edges, too:

Thanks for testing @miina!

"Almost" works since rotation doesn't seem to work anymore, probably we'll need to add another wrapper for the animations so that it wouldn't collide with the rotation wrapper.

I'm actually seeing odd behavior for resizing as well, didn't happen on develop, could you confirm if you see the same? (Resizing from one edge seems to move the block from other edges, too

The issue wasn't a conflict between the transform properties, but that the :root selector was wrongly removed by postcss-preset-env, which broke lots of things.

Resizing and rotation now works again as expected.

In some animation cases, for example in case of Fly In Bottom, the resizing handles are visible while the animation is happening, could we remove those for the animation time?

As long as the animation is playing, resize handles should actually be hidden:

I'll try to improve that though 👍

Thanks for the fixes, will test again shortly.

As long as the animation is playing, resize handles should actually be hidden:

Maybe it's the set transition time why it takes some time to hide?

Uhm, I think I just found a bug related to animation 🚨

When a block is saved, the animate-in-delay and animate-in-duration attributes in the resulting attributes contain only numbers, instead of numbers with an ms suffix... That means AMP just ignores them and there's no delay or anything on the frontend

Edit: Fixed now

Should the page animation inspector panel perhaps include a list of the animations on the page? Or at least a count of them?

Currently even if there are no animations, the button "Play all animations" is still there and active even though nothing happens on click. Should the button perhaps be disabled if there are no animations on the page?

Maybe the button text could simply be play ${n} animation(s) and then it would be obvious why the button is disabled if the count is zero?

Should the page animation inspector panel perhaps include a list of the animations on the page? Or at least a count of them?

This was suggested by Jonny as well above, but I had some reservations about this being the right place for such a list. See #3104 (comment). I do like the suggestion of using a count in the button label though.

Currently even if there are no animations, the button "Play all animations" is still there and active even though nothing happens on click. Should the button perhaps be disabled if there are no animations on the page?

Hmm I already implemented this in 41138b0 🤔 There's even a test for it. But perhaps there is some edge case. Will look into it.

Currently even if there are no animations, the button "Play all animations" is still there and active even though nothing happens on click. Should the button perhaps be disabled if there are no animations on the page?

Hmm I already implemented this in 41138b0 🤔 There's even a test for it. But perhaps there is some edge case. Will look into it.

If I add an element with an animation, the "play all" button appears on the page. If I remove the animation from the element, the "play all" button is correctly removed. But if I delete the element outright without first setting the animation to "none", the "play all" button sticks around still thinking there's an animation on the page.

If I create a cascading sequence of animations, so element 1 plays immediately, element 2 plays after element 1 and element 3 plays after element 2, the "play all animations" action gets stuck after the second animation - the third one never starts. This does work correctly in "preview", it's only in the editor with the "play all animations", that third level animations don't play.

I also managed to set up a longer chain, where one of the chained animations played immediately even though it was set to play after an element, that never actually played. I can't recreate it though.

If I create a cascading sequence of animations, so element 1 plays immediately, element 2 plays after element 1 and element 3 plays after element 2, the "play all animations" action gets stuck after the second animation - the third one never starts. This does work correctly in "preview", it's only in the editor with the "play all animations", that third level animations don't play.

While the page animation playback is in progress (or stuck as in this case and will never complete until I press the "stop" button), I can still select other blocks on the page, change them, move them, delete them, etc.

It might be a good idea to abort the animation playback as soon as the page loses focus/selection.

It might be a good idea to abort the animation playback as soon as the page loses focus/selection.

Gutenberg has a withFocusOutside HOC to detect when focus leaves an element, but it only works for class components. Maybe I can replicate that with useEffect...

But if I delete the element outright without first setting the animation to "none", the "play all" button sticks around still thinking there's an animation on the page.

Ah! Since the animation store doesn't really do garbage collection for deleted elements, the list included invalid items. Can circumvent this by filtering the list directly in the component.

If I create a cascading sequence of animations, so element 1 plays immediately, element 2 plays after element 1 and element 3 plays after element 2, the "play all animations" action gets stuck after the second animation - the third one never starts.

This should be fixed now

It might be a good idea to abort the animation playback as soon as the page loses focus/selection.

Haven't found an easy way to do this. I am inclined to leave this extra hardening for later so we can get this in for now.