Re: [web-animations] AnimationTimeline comments

(2014/05/20 2:17), Kristopher Giesing wrote:
> I guess I am thinking of this as being more of an intrinsic property,
> like the children of a DOM node.  This is expected to change over time,
> but semantically it always exists and is owned by a specific parent object.
>
> If on the other hand the semantics are more like getElementsByTagName,
> where ownership is spread out among many parents and the method is
> performing a collection operation across them, then it makes more sense
> to have an object-creator.

I think the latter case represents the correct semantics, or will do in 
the future due to the following kind of usage:

a) SVG integration. The timing of SVG animations is relative to their 
outermost SVG element of which there may be several in a document. I 
think we will end up representing this in the API as a nested SVG 
timeline under the document timeline. You'd be able to call 
getAnimationPlayers on either timeline and get either all the animations 
in the document, or just those in a particular SVG document fragment. As 
such the players could be children of one timeline and descendants of 
another.

b) Integration with scroll position and touch events. There's lots of 
interest in driving animations from scroll position and touch events. I 
think we might model this by treating the scroll container/touch source 
as a timeline and making the player do the mapping from position to 
time. In this case it seems more natural to think of the timeline as a 
passive source of time values and the player as the active subscriber. 
In this case timelines don't really own the players. It might even make 
sense to have players that merge values from two timelines.

Which makes me wonder if window.getAnimationPlayers(timeline) would make 
more sense?

Brian

Received on Tuesday, 20 May 2014 00:56:13 UTC