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

Have we considered just using an explicit priority, with creation time (or
TFI, or some other mechanism) as a tie-breaker?

- Kris

On Tue, Jul 14, 2015 at 4:37 PM, Shane Stephens <shans@google.com> wrote:

> 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
>