[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

Received on Thursday, 13 March 2014 23:38:45 UTC