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

Replying in this thread to maintain the context.

I think that would be good. I'm afraid I can't quite remember why
> creation ordering is better or why this proposal is better. I'm not
> opposed to it but I'd like to give others a chance to check it over too.
>
> Would you mind writing quick summary of the proposal with rationale for
> those who haven't been following this thread? (And to that end, starting
> a new thread might be better.)
>

I'm going to generally talk about why changing the order from creation time
is bad, and present specific proposals in a future email. But let's start
by quickly surveying the orderings provided by declarative animation APIs:

* SMIL has animation start time ordering. Thus timing information is used
to determine priority, which means that the two can't be different. If you
want a different priority to start time (e.g. you want an animation that
starts 3s into a sequence to be lower priority than the animations that are
already running) - you just can't. In practice, there are partial
mitigations - transform animations can be run on parent nodes (i.e. complex
animations require extra DOM content); non-transform additive animations
are somewhat insensitive to priority (but not entirely).

* CSS has text declaration ordering. CSS animation order is governed
entirely by animation name order.

>From the very first face-to-face meeting discussing web animations we have
agreed that the SMIL model is flawed. Over time we've evolved a few
different approaches, but until recently we had settled fairly stably upon
creation time ordering - that is, the order of creation of animations
dictates their priority. This gives a model that is about as similar as a
script API can be to CSS animations.

Recently, Brian introduced a proposal to try and solve some issues he'd
noticed with what happened when CSS animations were accessed via script and
'converted' to script animations.

Brian's proposal is to introduce a third sort of ordering -
transition-from-idle (TFI) ordering. Transitioning from idle is currently
somewhat of a secondary concept in web animations - the normal flow is to
create an already running animation (using element.animate), then either
let it run to completion or cancel it - so at first blush this proposal
looks a lot like the existing behavior. However, looking into the future,
constructors for Animations, Effects and Groups will begin to produce
stronger differences.

My alternative proposals maintain creation ordering and use a different
approach to solve the conversion issues. This is primarily because I think
that creation ordering is much more usable than TFI ordering, and worth
preserving. I have three main reasons for thinking this:

(1) TFI ordering has weird behavior:

take the following script:
var a = new Animation(...);
var b = new Animation(...);
b.play();
a.play(); // a has priority over b.
b.play(); // b does not have priority over a. Huh?
b.cancel();
b.play(); // b has priority over a.

Unless you've internalized the state machine for animations, the behavior
is hard to predict.

In contrast, creation ordering would guarantee that b always has priority
over a, as it was created second. If the author wants to switch that
priority, they simply switch the first two statements. It's a simple model
and it's easy to reason about.

(2) With TFI ordering, priority changing depends upon state changes. This
means that complicated code has hard-to-reason about effects on priority.
This is somewhat of a decent into the mistake that SMIL made - priority is
now tied to a feature of the animation engine that users want to use for
reasons other than priority.

In particular, if you want to cancel and later restart an an animation that
is at the bottom of the stack (but maintain the ordering), TFI ordering
requires you to sequentially cancel, restart, and reset currentTime on
every other animation in the stack.

(3) It is idiomatic to create animation resources separately from their
scheduling. We've already seen a desire to do things like this with
declarative animation and triggers, or with time sheets.

Creation time ordering ties animation priority to animation creation, which
means that you think about the order in which animation resources will
layer at the point where you're creating the resources.

In contrast, TFI ordering means you need to think about animation resource
ordering at each point that you start an animation. This is slightly better
than start time ordering, but not much - for example, it means that if
you've started other animations in the wrong order with respect to the
animation you're about to start, you are out of luck unless you want to
apply potentially global updates (your only available operation is to move
an animation to the top of the priority stack). For another example, how do
you slot a newly played animation in between a high-priority animation and
a low-priority one? You can't without restarting the high priority
animation.

I hope these arguments give a good sense for why I'm opposing the idea of
moving away from creation-time ordering. Any questions / counter-arguments?

Cheers,
    -Shane