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

On Tue, Jun 23, 2015 at 11:04 AM Brian Birtles <bbirtles@mozilla.com> wrote:

> On 2015/06/22 16:57, Shane Stephens wrote:
> > An alternative proposal:
> > CSS animations use sequence number as priority, and are created in tree-
> > and list- order. CSS Animations are still prioritized absolutely above
> > script animations (there are two lists). Changing an animation-name
> > property triggers an update of all listed sequence numbers. So:
> >
> >     elem.style.animation = 'a 2s, b 3s, c 4s'; // a: 0, b: 1, c: 2
> >     let b = elem.getAnimations[1];
> >     let c = elem.getAnimations[2];
> >     elem.style.animation = 'a 2s, d 5s'; //a: 3, d: 4
> >     c.play(); // c promoted to script animation, keeps sequence number
> >     b.play(); // b promoted to script animation, keeps sequence number
> >     elem.getAnimations(); // what is the order here? b,c,a,d
>
> Forgive me for being dense, but I don't understand what's being proposed
> here. Why would c.play() / b.play() promote to a script animation? And
> what does that mean here? Does it mean it no longer reflects style at
> all? Or just for the sake of ordering? Would pausing change anything?
>

Removing 'b' and 'c' from elem.style.animation cancels them. Calling play
restarts them, and it should restart them as script animations, not CSS
animations.

    elem.style.animation = 'a 2s, b 3s, c 4s'; // a: 0, b: 1, c: 2
    let b = elem.getAnimations[1];
    let c = elem.getAnimations[2];
    elem.style.animation = 'a 2s, d 5s'; //a: 3, d: 4
    c.play(); // c keeps sequence number
    b.play(); // b keeps sequence number
    elem.getAnimations(); // what is the order here? b,c,a,d


> > Script animations have preserved text order in terms of their
> > *definition* (which is important, see below).
>
> I don't understand this sentence.
>

'b' is lower priority than 'c' because it was originally defined by
elem.style.animation in that order.


> > Question: does getAnimations sort script animations separately from CSS
> > animations? I think it probably should so that the order reflects
> > application priority.
>
> Yes. See the linked-to spec text in my previous mail as well as the
> outline in the GitHub issue.[1]
>
> >     elem.style.animation = 'a 2s, b 3s'; // a: 0, b: 1
> >     getComputedStyle(elem).animationName; // flush style
> >     elem.style.animation = 'a 2s, c 4s, b 3s'; // a: 2, c: 3, b: 4
> >     let anims = elem.getAnimations(); // returns a, c, b
> >     elem.style.animation = '';
> >     anims.forEach(anim => anim.play());
> >     elem.getAnimations(); // returns a, c, b.
> >
> > So this works nicely now too.
>
> It also works if you use start order.
>

Well, yes. I'm proposing an alternative to using start order, so it should
probably have similar properties.


> > Taking your weirdness:
> >
> >     var moveLeft = new Animation(...);
> >     var moveRight = new Animation(...);
> >     moveRight.play();
> >     ...
> >     moveLeft.play();
> >     // Wait, why doesn't moveLeft take effect?
> >
> > Let's extend it another step, assuming that transitioning from idle does
> > update priority:
> >
> >     var moveLeft = new Animation(...);
> >     var moveRight = new Animation(...);
> >     moveRight.play();
> >     ...
> >     moveLeft.play(); // moveLeft takes effect
> >     moveRight.play(); // wait, why doesn't moveRight take effect?
>
> Yeah, fair point. (Although the answer is simply, "because the animation
> is already started".)


The answer is strictly less simple than 'because you defined them in that
order'.

It's also easier to modify animation declaration order than animation play
order in many circumstances (e.g. animation declaration can be pulled
out-of-line and animations can be speculatively created without much
consequence but invoking play is often conditionally done, in the middle of
program logic).


> But I don't understand how the proposal here fixes
> this. Are you suggesting play() updates sort order? Can you spell out
> the proposal in detail?
>

No, I'm suggesting that we don't modify the semantics of the JS API, and
fix the (CSS-specific) problem by rewriting CSS sequence numbers when the
CSS animation property is changed instead.

Cheers,
    -Shane


>
> Thanks!
>
> Brian
>
> [1] https://github.com/w3c/web-animations/issues/62
>