Server Notice:

hide

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 
 
Agenda:
 
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
 
1. STATUS UPDATE
================
 
Brian:
* 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()
 
Shane:
* Not much since last meeting, just reading Brians documents
 
2. PLAYBACK CONTROL PROGRESS
==============================
 
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
 
4. INTERPOLATION MODES
======================
(Brian)
 
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.
 
5. OTHER TIMING FUNCTIONS
=========================
(Brian)
 
In reviewing other APIs I notice some of them have a *lot* of timing functions on offer, e.g.
 
QML:
* 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
Raphael:
* 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
CA:
* linear, easeIn, easeOut, easeInOut, default, bezier
jQuery:
* swing, linear
  Most others defined by plugins, e.g. http://api.jqueryui.com/easings/
Android:
*  AccelerateDecelerateInterpolator, AccelerateInterpolator,  AnticipateInterpolator, AnticipateOvershootInterpolator,  BounceInterpolator, CycleInterpolator, DecelerateInterpolator,  LinearInterpolator, OvershootInterpolator
WPF:
*  BackEase, BounceEase, CircleEase, CubicEase, ElasticEase,  ExponentialEase, PowerEase, QuadraticEase, QuarticEase, QuinticEase,  SineEase
  Note, ElasticEase uses parameters: 'oscillations' and 'springiness'
d3:
* linear, poly(k), quad, cubic, sin, exp, circle, elastic(a, p), back(s), bounce
mathBox:
* 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.
 
6. MULTIPLE TARGET ELEMENTS
===========================
 
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 @ https://etherpad.mozilla.org/CwdFZELqCn
 
 
7. GROUPS
=========
 
Shanes proposal in brief:
1. Use TimingGroups as compositor groups.
2. parameterize merge.
 
 
Well talk about this at the face-to-face.
 
8. FACE-TO-FACE DRAFT SCHEDULE
===============================
 
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