- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 20 May 2014 09:55:43 +0900
- To: public-fx@w3.org
(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