Server Notice:


Public Pad Latest text of pad uDxc2Hwa8n Saved Oct 16, 2012

Web Animations Meeting 30
1. Google meet-up in Tokyo
2. Licensing
3. Feature request: timeline from guestures
1. Google meet-up in Tokyo
Everything looks good. Well present the same material as SVGOpen.
2. Licensing
Apache 2.0 is ok with Google.
If Adobe is ok with it, Google can own the code. If possible, it would be nice to leave it on GitHub so we can accept pull requests from contributors. Brian suggests GitHub might be better from a community involvement point of view.
Shane to ask if we can continue to host on GitHub or if Google require us to use
Brian to email Vincent regarding code hosting and CLAs
Google uses the following CLAs:
3. Feature request:  timeline from gestures
It would be good to be able to replace the timing with value derived from gestures. This is basically equivalent to replacing the timing model with a substitute timing model that gets its input from the gestures rather than the system clock.
We had a similar question at SVGOpen about, for example, can you drag the door and have it open smoothly?
No concrete proposals yet for how to represent this declaratively but we are confident the architecture permits this to be added (by simply substituting out the timing model), perhaps in a subsequent version if not immediately.
4. Default value of fill
Our experience with writing the demo shows that more often than not, you want fill: forwards. We think we probably should make this the default value even if this differs from CSS and SVG (which both remove the animation effect after it has completed by default).
We still are not sure how to make animations that fill performant, i.e. relive the UA of having to hold on to all past animations with a forwards fill mode since they still affect their target property/attribute. We might need implementation feedback to resolve this.
Issues for another time:
* Specified start times should not update when moving animations between  containers, but automatically calculated start times should. (However,  if the start time was specified with the intention of being a relative  amount from the parent's iteration time then it *should* update). We (Shane and Brian) also discussed adding startTime as a parameter to add, and always updating startTime.
* Sensible behaviour for changePlaybackRate(0)
    -- If you call changePlaybackRate(0) mid-way through an animation you  expect it to pause. Currently it does not because a playback rate of  zero means an infinite duration which means you never get past the  starting point. You can work around this by adjusting the  iterationStart, or by just special-casing 0 to make it actually pause,  or you can just say "that's the model". What do you prefer?
* Integrating with video and audio... is this really going to work?
    -- video and audio need a concept of direction but our timing functions  etc. mean all bets are off regarding the direction of the next sample.  And its not just enough to disallow certain timing features on the video  since these things can happen all the way up the tree. Maybe we need  some process where we approximate the effect... e.g. walk up the tree,  ignore timing functions, work out the direction, playbackRate etc. and  then apply those properties to the video itself (behind the scenes?)