Web Animations Spec Feedback

I was in the process of re-architecting one of my earlier JavaScript
animation frameworks and at the same time, porting it to Objective-C, when I
discovered Web Animations. A lot of my work seemed to reflect similar
thinking, and I've spent the past few days trying to align my implementation
with the current version of the spec.

 

I've purposely diverged from the spec in a few places, and I thought that my
reasoning might provide another perspective on the great work that is being
done. I wouldn't consider myself an "animation framework expert," but I have
been down this road a few times.

 

*         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.

*         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've removed nextSibling completely, as I've found no need for it.

*         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.

 

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!

 

Mike Swanson

mdswanson@comcast.net

http://blog.mikeswanson.com