Re: [web-animations] Simplifying timing groups

Hi Dirk,

I think you might be misunderstanding what Brian is proposing.

Web Animations has Timelines, which provide linear time to animated
content. It is impossible to apply timing functions to Timelines -
animations are always linearly related to one another. When you say "At the
end the UA needs to guarantee that it can calculate all these mappings in
time to be a real time system. And linear mapping is just the easiest and
simplest way to map time lines", well that is precisely what we have right
now, and nobody is proposing that this should change.

The animated content which attaches to Timelines consists of Timed Items.
Timed Items are basically the core timing model abstraction. A Timed Item
gives you some basic abilities, like repeating playback of content multiple
times (iterations), delaying the onset of content (delay), etc. One of
these abilities is to apply a timing function to the content.

Timed Items are hierarchical - you compose an animation by building very
simple pieces and defining how they relate to each other. Leaf nodes of
this hierarchy relate a single set of keyframes to a single target. The
leaves are related to each other using Par Groups ('these things all happen
together') and Seq Groups ('these things happen in sequence'). Timing
Groups *are* animations - from the perspective of the Timeline they are the
same class - it's just that they're animations which are composed of
smaller animations. In particular, an animation defined by a Timing Group
is a unit - you can't pause parts of it independently and it is intended to
represent a single thing.

What Brian is proposing is that non-leaf-node Timed Items shouldn't be
allowed to have timing functions, but leaf node Timed Items should. I think
this makes the model much more complicated, i.e. actually harder for people
to understand. It also takes away some nice features.

For an example of the complication:
"I have two things that I can play, by calling timeline.play(thing). This
one moves this box to the right, and this other one moves these two boxes
towards each other. How come I can ease one of them but not the other?"

The point that was raised multiple times is that the first level does not
> need to address all possible use cases that authors do or may have. Instead
> it is important to have a consistent model and consistent implementations.
> For authors this is actually a lot more important than a rich and
> "complete" model. I also have doubts that this is an issue for one
> implementation. The mapping must be done in all implementations that follow
> the spec. It sounds reasonable to defer certain features if they can not be
> implemented initially. If that causes inconsistencies in the model, we have
> to address these.
>

I'm all for the removal of extra functionality. I've supported (and in some
cases pushed for) the removal of templates, state machines, the
simplification of timing functions, the removal of media integration,
massive simplifications of the way timed items work, and a host of other
changes that reduce the model complexity and surface area. I'm taking a
stand with this one because I think it makes the model harder to understand
and bigger. I also completely disagree about the implementation complexity.

Furthermore, Brian isn't talking about just deferring this feature. He
wants to remove it because he doesn't like the implications timing
functions have on the event model. Unless we defer the event model at the
same time, we're very unlikely to be able to reintroduce timing functions
later. Removing it from version 1 of the specification also breaks a single
concept into two (Timed Items now become AnimationTimedItems and
GroupedTimedItems, or something). Once code relies on this, there's no way
we can go back.

Cheers,
    -Shane