W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2015

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

From: Shane Stephens <shans@google.com>
Date: Wed, 15 Jul 2015 06:04:14 +0000
Message-ID: <CAGTfzwQdTSWNeu6ht232=YL_gAn0JVUvBSQ6uMf2A5gw2724Qw@mail.gmail.com>
To: Brian Birtles <bbirtles@mozilla.com>, "public-fx@w3.org" <public-fx@w3.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>
On 2015/07/15 8:37, Shane Stephens wrote:
> > (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.
> It seems equally true to say that its idiomatic to create animation
> resources separately from their priority.

I'm not sure that this is true. Do you have examples? SMIL doesn't let you
do this, nor would time sheets. Even CSS ties priority to (timing property)

> > 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.
> That seems odd to me. It seems more natural to set up the animations
> with all their properties and then think about how to combine them.
> That's where I was going with the FTFI proposal.

Doug and just I discussed two conflicting examples:

(1) I have a set of animations that have a known stacking order, and I just
want to apply them in response to (independent) events. With creation
ordering, I create them in the required stacking order. With FTFI, I need
animations.map(function(animation) { animation.play(); animation.cancel();

(2) I have a set of animations with a stacking order that needs to follow
their triggering order. I can't do this with creation ordering, and I can
only do this with FTFI if the animations never repeat.

I guess that I find case (1) more likely than case (2) - but we can fall
back on explicit examples. Here are examples of (1):
* an articulated robot with movements triggered by events
* A planetary system with rockets that can take off and orbit their
respective planets in response to events.

I can't think of examples that fit into (2) off the top of my head. Do you
have any?

> In contrast, TFI ordering means you need to think about animation
> > resource ordering at each point that you start an animation.
> Again, having to think about priority when you create animations seems
> unfortunate. That's something you'll often want to delegate to a factory
> method of some kind, and then take care of the controlling logic elsewhere.

Which is fine, because then you're delegating order to factory method

>  > 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.
> This is where creation-time ordering seems weakest. With TFI you can
> shuffle animations by restarting them (saving their currentTime in
> between if needed). With creation-time ordering you have to create
> entirely new animations. The again, the same problem exists for FTFI. I
> guess clone()-ing is not that bad as an interim measure.

Right, we definitely need that ordering tweak at some point soon.

> > 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?
> I guess I'm not thrilled with any of the options. I was hoping I was
> forgetting something amazing about creation-time ordering!
> As Kris says, and as we've often acknowledged, we'll need a mechanism
> for explicitly setting priority in the future.
> Until them maybe creation-time ordering is ok. I was hoping to see how
> its better than FTFI but they seem much of a muchness to me.

In the absence of compelling examples for case (2) above, FTFI is basically
creation ordering with a required extra manual step.


> Best regards,
> Brian
Received on Wednesday, 15 July 2015 06:04:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:54 UTC