[web-animations] Simplifying timing groups

Hi public-fx,

I have a proposal to simplify Web Animations by not allowing timing 
functions on groups (at least not yet, see the last part).


MOTIVATION:

Allowing arbitrary timing functions on groups complicates Web Animations 
in many ways:

i. It means you can't convert from an animation's local time to the 
corresponding document time since timing functions are not always 
invertible. This introduces all sorts of complexity. For example, for 
event handling to report both a local time and document time for an 
event we have introduced uneased timing[1] which is not well-liked and 
as an alternative we have considered some fairly arbitrary approximations.

It also introduces some as-yet unresolved questions such, "If a timing 
function on a group causes a child to oscillate between being in and out 
of the active phase repeatedly, perhaps even a dozen times in 100ms for 
a spring function, do we dispatch events for every one of those 
transitions?" (And if we have real spring functions the number of 
crossings would depend on how you evaluate the function and could be huge.)

ii. It introduces complexity when timing functions on groups overshoot 
the [0, 1] range since then children won't stretch as they would if the 
timing function was applied directly to them, but rather will go into 
their fill behavior which will result in them being clipped. We 
discussed this previously[2] and considered adding special handling 
specifically for this situation which feels at least a little bit hacky 
(it involves passing extra state around and is only applied to children 
that touch the edge of their parent).

iii. It complicates implementation since this feature makes it difficult 
to decompose timing hierarchies into simple animations that could be 
passed off to another process or even another API. Without this feature, 
any timing hierarchy could potentially be flattened down to a series of 
very simple sub-animations. (For example, an iteration count of a group 
would be represented by producing several sub-animations, one for each 
iteration. A direction setting on a group could be represented by 
flipping the playback rate on some of those sub-animations etc. On the 
other hand, splitting a timing function on a parent into pieces, then 
combining the appropriate piece with any timing functions already 
applied to the child's sub-animations, is far more complex.)

I'm not sure if implementations will actually take this approach but I 
think the fact that arbitrary timing functions on groups greatly 
complicates this approach is indicative of the complexity introduced by 
this feature.


OBSERVATIONS:

No other animation API I can find allows arbitrary timing functions on 
groups.

For example,

* Core Animation talks about groups and timing functions but the groups 
in this case correspond to our keyframe animations. That is, a set of 
properties being animated together.

* GSAP, which has an impressive feature set, has no 'ease' property on 
TimelineLite / TimelineMax.

* WPF which has, by far, the most complicated animation API I have ever 
seen, only has easing functions on animations.

* SMIL3, as discussed later, which is infamous for its complexity, does 
not allow arbitrary timing functions on groups.

This begs the question, do we really need this?

A further implication of the fact that other APIs don't provide this 
facility is that it is therefore probably quite difficult to implement 
the Web Animations model on top of an existing animation API.


PROPOSAL:

I propose making timing functions a property of animations only, at 
least initially. This would have the following benefits:

* Events become a lot simpler. There is no need for uneased timing or 
approximations of timing functions and no questions about which events 
get dispatched.

* In general, provided the 'current iteration' of each parent is known, 
it is possible to convert from an animation's local time to document 
time which may be useful in a number of contexts (it may, for example, 
be something we expose via the API in future).

* There is no need for special overflow fill handling.

* Implementations can easily flatten timing hierarchies into 
sub-animations and pass them off to a separate process and possibly 
another animation API.

* Media references are not required to support timing functions 
initially. If timing functions are useful there, we can determine the 
sort of timing functions that are readily implementable and restrict the 
set of timing functions permitted accordingly. For example, overshoot 
doesn't make much sense for media. Likewise, some features of chained 
timing functions probably don't make much sense for anything other than 
animations (like the keyframe alignment feature).

* For timing groups, we can likewise add a restricted set of timing 
functions later as needed. Due to the complications noted above, such 
timing functions could be restricted so that they are invertible and 
can't go outside the [0, 1] range. Note that this is what SMIL3 does.[3] 
For time containers (groups) it defines time manipulations and these 
include only playback rate control, auto-reversing, and 
accelerate/decelerate (which can be combined to produce ease-in / 
ease-out effects where the result is invertible and in the range [0, 1]).


There are a number of options for how we might represent this in the API 
but I'd like to start by deciding about the model.

Best regards,

Brian

[1] http://www.w3.org/TR/web-animations/#uneased-timing
[2] http://lists.w3.org/Archives/Public/public-fx/2013AprJun/0184.html, 
item 15
[3] http://www.w3.org/TR/SMIL/smil-timemanip.html#TimeManip-Overview-support

Received on Thursday, 8 August 2013 03:25:49 UTC