RE: [web-animations] Re: Web Animations Spec Feedback

Thanks for the reply, Brian. I had already read through the minutes[1], and
it does sound like the concern is understood. I'm happy to hear that the
'player' member is being reconsidered.

Regarding 'previousSibling' (which I had erroneously referred to as
'priorSibling' in my original message), I have attached a diagram that shows
how I view the 'previousSibling' relationships in an animation group
hierarchy. It's possible that I'm not conforming to the true definition of
'previousSibling' as it relates to the spec, and if that's the case, feel
free to call it 'previousAnimation' if it makes more sense. Regardless of
its name, having a reference to the prior animation makes it easy to
dynamically infer a TimedItem's 'startTime.'

As you can see in my diagram, each TimedItem in a Sequence group (except for
the first TimedItem) has a 'previousSibling' that refers to the previous
animation. For Parallel groups, the 'previousSibling' is null. My
'previousSibling' implementation is dynamic and uses the following general
logic:

* If the timed item has a parent animation group that is Sequential,
          return the prior ordered item in the timed item list, unless it is
the first item, and in that case, return null.
* Otherwise,
          return null.

The logic for 'startTime' is also dynamic:

* If 'previousSibling' is null,
          return 0.
* Otherwise,
          return the previous sibling's 'endTime.'

It's worth noting that I have a single AnimationGroup class that has a
Boolean that indicates whether it's sequential, so this is a trivial test.
It would get a bit less elegant if you had to check the class of the parent
(as in the current proposed model of two different group classes).

As you say, it's possible that other group types may exist in the future.
However, I can't recall running into another type. Even if I did, it would
be trivial to create a group where the 'startTime' is settable.

The benefit of the dynamic 'previousSibling' and 'startTime' properties is
that my animation classes and groups can remain mutable, and all of the
dynamic calculations continue to work. There is no "re-setting" or
recalculating of startTimes to deal with. I can also easily move from
sequential to parallel group behavior dynamically with the setting of a
single Boolean on my group class.

Regarding the other feedback, your reasoning makes perfect sense to me. You
have a lot of different frameworks to serve, and I understand those
constraints.

Mike

-----Original Message-----
From: Brian Birtles [mailto:bbirtles@mozilla.com] 
Sent: Thursday, March 13, 2014 4:38 PM
To: public-fx@w3.org; Mike Swanson
Subject: [web-animations] Re: Web Animations Spec Feedback

Hi Mike,

Thanks for your helpful feedback.

(2014/03/11 9:03), Mike Swanson wrote:
> .The biggest change I've made is to remove a TimedItem's reference to 
> its Player. I really dislike circular references (Player -> TimedItem 
> -> Player), and I try to avoid them whenever possible. I see a lot of 
> logic in the spec that is dependent on whether the TimedItem is 
> associated with a parent animation group or a player, and this seems
problematic.
> If a child TimedItem absolutely needs information about a Player, I'd 
> strongly recommend an interface (like TimeProvider or TimeSource) that 
> provides time samples. That way, the Player and an animation group can 
> both be TimeProviders, but only one can be active at any given time.
> This may also simplify the either/or logic that's currently in the spec.

We discussed this at our F2F meeting yesterday. You mightly like to read the
minutes[1] and see if we have understood your concern correctly.

We decided to mark the 'player' member as at risk, and, for similar reasons,
getCurrentAnimations. As a result 'players' become the fundamental pieces
authors work with. In fact, it is not possible to go from an animation to
its player.

> .The start time setter of a TimedItem seems unnecessary. If a 
> TimedItem has a priorSibling, the start time is the end time of the 
> prior TimedItem. If there is no priorSibling, the start time is 0.
 > .My single animation group is called an AnimationGroup, and it takes a  >
"sequential" Boolean in its constructor. All children of a  > non-sequential
(i.e. parallel) group have no priorSibling, so their  > start time is
inherently 0. When the group is initialized as sequential,  > all children
but the first have correctly assigned priorSiblings. This  > provides the
expected behavior without having to schedule/set start  > times. Better yet,
if the children are altered, no start times have to  > be re-set.


I think the approach you outlined here is interesting.

However, I'm concerned that inserting into a sequence is more complex and
error-prone (presumably the implementation must break cycles etc.). 
Does the indexing reflect the links set up by priorSibling or is it removed?
Are multiple items allowed to have the same priorSibling? How do you
traverse children? I may have misunderstood all this or you may have
proposals.

(It seems a little too close to SVG's syncbase timing which we certainly
want to avoid!)

I'm also somewhat concerned about how well this scales to different types of
groups we may add in the future.

> .I've removed nextSibling completely, as I've found no need for it.

I think in the model you proposed above that makes sense (and, indeed, it
would be problematic to keep it).

As the model stands, the interface is intended to align with the most recent
DOM interfaces.[2] I think it's useful to keep it for consistency and so
generic algorithms can be used.

> .It seems to me that there are two logical directions for a timed item:
> forwards and backwards. The additional "directions" described in the 
> spec sound like behaviors (and the word "normal" is also confusing). 
> So, my implementation has only two directions, and each TimedItem has 
> a "reverses" Boolean that indicates whether the direction reverses or 
> not on each alternating iteration. Based on prior experience, I've 
> found that splitting the direction and reversing behavior into two 
> properties makes it much easier to understand conceptually.

I agree very much. However, we are trying to align with CSS as best we can
so that Web authors can move between the API and the CSS syntax without
having to do too many mental gymnastics. If it were up to me, we would not
have 'direction' at all, only 'playbackRate' and 'alternates', but I think
it is best to align with CSS here.

> Other than these few areas, I've found the spec to be very 
> comprehensive, and it's enabled me to build an Objective-C library 
> that behaves as-expected. Thank you again for the excellent work!

Thank you very much!

Best regards,

Brian

[1] http://lists.w3.org/Archives/Public/public-fx/2014JanMar/0099.html
[2] http://dom.spec.whatwg.org/#node