Server Notice:


Public Pad Latest text of pad pBOIanK3jm Saved Jan 23, 2013

Meeting 42:
Web animations minutes, 22 / 23 January 2013
Present: Dmitry Baranovskiy, Shane Stephens,  Douglas Stockwell,  Brian Birtles 
1. Status update
2. Playback control progress
3. Timing object
4. Interpolation modes
5. Other timing functions
6. Multiple target elements
7. Groups
8. Draft face-to-face schedule
* Drawing pictures
* Playback control research for SVG (see below)
* Timing object thoughts and proposal (see below)
* Spec edits
 - Rename TimedItem.targetElement to target
 - Define states for timed items
 - Add Document.getCurrentAnimations()
 - Add Element.getCurrentAnimations()
 - Remove TimingGroup.getActiveAnimations()
* Not much since last meeting, just reading Brians documents
Any further thoughts?
One issue that has arisen is how to approach SVG which seems to require two-levels of play control:
Discussed this document (specifically, update 3 regarding SVG play control). We all think that:
the specifics of nested pause/play behaviour is probably not being relied on, so we have an opportunity to make this behaviour consistent across the browsers
we can implement any of these behaviours relatively easily within the Web Animations framework
probably we should go with Operas approach as the most useful that is compliant with what is specified
(Specifically this means essentially flattening nested SVG elements for the purposes of time containment and remoting calls to pause etc. on nested SVG to the root SVG element)
Remainder of discussion regarding play control deferred to Web Animations F2F in Sydney 11 15 Feb
3. Timing OBJECT
Any further ideas? Dmitry? Defer to F2F?
Brief discussion of CSS integration should CSS have the following properties:
  should CSS-derived animations be editable from JavaScript?
  if so, should it be possible to revert a CSS-derived animation back to its original, CSS-only state?
 Yes to and means we need _some form_ of timing sharing (or at least part of it). Its possible we can just expose this through CSS integration rather than as part of the full Web Animations spec. Its also possible to accept and not for now. Whether either of these possibilities is desirable is a matter for discussion.
Remainder of discussion regarding the Timing object and sharing deferred to Web Animations F2F in Sydney 11 15 Feb
Just  a curiousity, if we wanted to support, say, interpolation of colours in HSL space as well, where would we hang that off the API?
Theres two parts this:
automatic rules for interpolating between any two of a given multi-specced value type (color, length, transform, etc.)
manual specification of rule choice to provide for specific effects
Doug:  Similar to this, we might want to support requesting non-numeric interpolation (just snapping to the closer keyframe) for types that are normally interpolable.
This fits under point .
Brian: This is similar to SVGs calcMode attribute
Shane: Looks like we can support Dougs request using per-keyframe timing functions that are steps at 0.5.
Agreed it doesnt look like is needed for version 1 and that we can add this functionality to the API later if it proves necessary (e.g. by attaching an Interpolator to AnimationEffect that subclasses call out to). Until then, authors can use CustomAnimationEffect to produce specialised interpolation.
One case to bear in mind is SVGs color-interpolation property:
which applies to animation of colours.
Another thing to keep in mind is that CSS always interpolates in premultiplied color space. Do we want to do this always too? Or provide more flexibility? It seems like SVG might be not premultiplied.
Outcome: we dont need to update the architecture but were going to need to pay attention to detail when specifying how colors are interpolated.
In reviewing other APIs I notice some of them have a *lot* of timing functions on offer, e.g.
* Easing -- 42 different types!!! Including "OutInBounce", "InOutElastic" etc.
    each types can also be tweaked by specifiying: overshoot, amplitude, period
    (not all properties apply to all types)
* Smoothing (similar to our merging?)
* Spring
* linear, easeIn, easeOut, easeInOut, backIn, backOut, elastic, bounce
Dojo Toolkit:
• linear, quadIn, quadOut, quadInOut, cubicIn, cubicOut, cubicInOut, quartIn, quartOut, quartInOut, quintIn, quintOut, quintInOut, sineIn, sineOut, sineInOut, expoIn, expoOut, expoInOut, circIn, circOut, circInOut, backIn, backOut, backInOut, elasticIn, elasticOut, elasticInOut, bounceIn, bounceOut, bounceInOut
* linear, easeIn, easeOut, easeInOut, default, bezier
* swing, linear
  Most others defined by plugins, e.g.
*  AccelerateDecelerateInterpolator, AccelerateInterpolator,  AnticipateInterpolator, AnticipateOvershootInterpolator,  BounceInterpolator, CycleInterpolator, DecelerateInterpolator,  LinearInterpolator, OvershootInterpolator
*  BackEase, BounceEase, CircleEase, CubicEase, ElasticEase,  ExponentialEase, PowerEase, QuadraticEase, QuarticEase, QuinticEase,  SineEase
  Note, ElasticEase uses parameters: 'oscillations' and 'springiness'
* linear, poly(k), quad, cubic, sin, exp, circle, elastic(a, p), back(s), bounce
* in, out, default
Most support custom functions. We are concerned about calling out to script during a sample for this. Perhaps we can accommodate timing functions that arent pre-defined by simple linear interpolation?
Proposal: spin Timing Functions off as a seperate specification. Ship v1 of Web Animations with just enough timing functions for CSS and SVG support.
Seems to be agreement on this. Done. Well keep the basic timing functions inside the Web Animations specification for now, until Timing Functions reaches maturity.
A while ago we decided that in the future we probably want Animation.targetElement to be able to target a list of elements in the future and so we should rename it to 'target'. That's fine, but it probably deserves a bit more thought. For example, *if* we do that, how could you cancel all animations that apply to element A without having side effects?
Maybe we should define cancelling in terms of removing an element from the target property of all animations? And is there are use case for being able to say "cancel all animations targetting A but keep their current value (i.e. freeze them)"? Or "cancel all animations targetting A but first fast-forward to the end"? (A number of APIs have a "finish" method for this)?
Anyway, this doesn't need to block FPWD but I'm just flagging it as an issue for now.
Another related issue, is *if* we allow target to refer to multiple elements, this might influence the way we map SVG to Web Animations.
For example, if version 1 of Web Animations Core only supports a single target BUT version 1 of Web Animations SVG Integration allows <animate select=".cloud" ... /> (and this is the current state of play), then SVGAnimationElement.getActiveAnimations() would probably return one Animation per matched target.
However, once target can support multiple elements it would be far more natural to return one animation with multiple targets but we would be unable to do this if content already expects one per animation. Then, of course, if <animate select=".cloud"> was defined such that when a newly matching element was found it started from the beginning, then in that case, the one animation per target would make sense.
One option might be to simply delay <animate select=".cloud"> until the API catches up.
Also, how does event dispatch work with multiple targets? What is the propagation chain?
Shanes proposal: templates make much more sense because they:
allow cancellation to be more logical
allow assemblages to be targeted by animation groups
Next meeting: Thurs Jan 24, 17:30 PST / Fri 25 Jan 12:30 AEDST / Fri 25 Jan 10:30 JST @
Shanes proposal in brief:
1. Use TimingGroups as compositor groups.
2. parameterize merge.
Well talk about this at the face-to-face.
1. Play Control
2. Timing (sharing, templating, separate object etc.)
3. Effect templating
4. Groups
5. Media Integration
6. Autoplay behaviour
7. Spec finalization and cleanup
  - motion path
  - CSS integration
  - color interpolation
  - ...
Next meeting: Sydney F2F, 11 - 15 Feb 2013 @ Google Sydney