Re: [web-animations] Ordering animations based on when they transition from idle

On 2015/06/22 13:10, Shane Stephens wrote:
> On Mon, Jun 1, 2015 at 2:39 PM Brian Birtles <bbirtles@mozilla.com
>     Furthermore, even if we
>     did require that, you'd get strange results when, for example, you do
>     the following:
>
>         elem.style.animation = 'a 2s, b 3s';
>         getComputedStyle(elem).animationName; // flush style
>         elem.style.animation = 'a 2s, c 4s, b 3s';
>         let anims = elem.getAnimations(); // returns a, c, b
>         elem.style.animation = '';
>         anims.forEach(anim => anim.play());
>         elem.getAnimations(); // returns a, b, c. What??
>
>
> This is slightly odd, but quite explainable and definitely a corner case.

I'm concerned these little oddities tend to lead to obscure bugs and I 
think it would be preferable to avoid them if we can.

>     I wonder if we should change the animation sequence number to be based
>     on when the animation last transitioned out of the idle state.
>
>     If we did that, the order in the first example would be 'a, d, c, b'. In
>     the second example, we'd get 'a, b, c' in both cases.
>
>     Doing this would also allow authors to alter the priority of animations
>     without having to regenerate them: simply cancel() and play() to push to
>     the top of the stack.
>
>     I think this is intuitive since cancelling an animation effectively
>     takes it out of any composition stack it might be contributing to.
>
>     What do you think?
>
>
> I'm not 100% sure that there's an issue that needs solving - these are
> really edge cases and as long as the behavior is consistent I think it's
> fine.

It fixes the inconsistency that a CSS animation/transition generated by 
CSS markup, but then disassociated from that markup, suddenly sorts 
differently based on some now opaque history of when stylesheets were 
processed. Indeed, that order might even be indeterminate if there were 
non-blocking stylesheet loads.

It also fixes the following weirdness:

   var moveLeft = new Animation(...);
   var moveRight = new Animation(...);
   moveRight.play();
   ...
   moveLeft.play();
   // Wait, why doesn't moveLeft take effect?

> One concern I have is that currently text order (or creation order) is
> inviolate which makes it easy to reason about; but that might be
> outweighed by the fact that if we made this change then authors could
> (to a degree) choose to reorder the animations.
>
> I guess the central question is whether we want authors to be able to
> reorder? If yes, I think we probably want to give them something nicer
> than this, and if we do then we can specify that CSS uses it to get
> prioritization right.

I think it's easier to reason about (of course I would say that!). If 
you're tied to CSS markup, that's where your order comes from. 
Otherwise, it's based on start order. Furthermore, to move between the 
two modes you have to explicitly break the link with markup and restart 
the animation (hence establishing the start order) so there are no 
surprises.

So I think this proposal makes the behavior more consistent and 
intuitive and happens to provide a basic means for shuffling animations 
without any overhead.

I guess my question is, what is the problem with the proposal? I didn't 
get any feedback on this for 3 weeks so I specced it[1][2][3], 
implemented it[4] and tested it[5] and in every regard it seems 
preferable to me than the old behavior.

Brian

[1] 
https://github.com/w3c/web-animations/compare/103c2ccb98bd...ce4e853582067
[2]https://rawgit.com/shans/csswg-drafts/animations-2/css-animations-2/Overview.html#animation-priority
[3]https://rawgit.com/shans/csswg-drafts/animations-2/css-transitions-2/Overview.html#animation-priority
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1171817
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1150810

Received on Monday, 22 June 2015 05:14:35 UTC