[web-anim] Web animations minutes, 22 / 23 January 2013

Web animations minutes, 22 / 23 January 2013

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.sNox0X6XAmx/latest
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. Grouped animation effects
8. Draft face-to-face schedule


1. STATUS UPDATE
================

Brian:
* Drawing pictures
 
https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/img/time-calculations.svg
 
https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/img/active-duration-calculation.svg
* 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 Brian’s 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:
 
http://www.w3.org/Graphics/fx/wiki/Web_Animations/Play_Control_Review#Update_.233

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 Opera’s 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?

Some thoughts: 
http://www.w3.org/Graphics/fx/wiki/Web_Animations/Shared_Timing

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). It’s possible we can just expose this through CSS 
integration rather than as part of the full Web Animations spec. It’s 
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?

There’s 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 SVG’s calcMode attribute

Shane: Looks like we can support Doug’s request using per-keyframe 
timing functions that are steps at 0.5.

➙ Agreed it doesn’t 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 SVG’s color-interpolation property:
   http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperty
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 don’t need to update the architecture but we’re 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.
 
http://qt-project.org/doc/qt-4.8/qml-propertyanimation.html#easing.type-prop
     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
    http://raphaeljs.com/reference.html#Raphael.easing_formulas
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
     http://dojotoolkit.org/reference-guide/1.8/dojo/fx/easing.html
CA:
* linear, easeIn, easeOut, easeInOut, default, bezier
 
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CAMediaTimingFunction_class/Introduction/Introduction.html#//apple_ref/occ/cl/CAMediaTimingFunction
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
 
http://developer.android.com/reference/android/view/animation/Interpolator.html
WPF:
* BackEase, BounceEase, CircleEase, CubicEase, ElasticEase, 
ExponentialEase, PowerEase, QuadraticEase, QuarticEase, QuinticEase, 
SineEase
   http://msdn.microsoft.com/en-us/library/ee308751.aspx
   Note, ElasticEase uses parameters: 'oscillations' and 'springiness'
d3:
* linear, poly(k), quad, cubic, sin, exp, circle, elastic(a, p), 
back(s), bounce
   https://github.com/mbostock/d3/wiki/Transitions#wiki-d3_ease
mathBox:
* in, out, default
   https://github.com/unconed/MathBox.js/blob/master/src/Animator.js#L280

Most support custom functions. We are concerned about calling out to 
script during a sample for this. Perhaps we can accommodate timing 
functions that aren’t 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. We’ll 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?

Shane’s proposal: templates make much more sense because they:
① allow cancellation to be more logical
② allow assemblages to be targeted by animation groups


7. GROUPED ANIMATION EFFECTS
============================

Shane’s proposal in brief:
1. Use TimingGroups as compositor groups.
2. parameterize merge.

We’ll 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 in Sydney

Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings

Received on Wednesday, 23 January 2013 02:13:11 UTC