Server Notice:


Public Pad Latest text of pad WMI4F0NGQV Saved Jan 15, 2013

Meeting 40:
Web animations minutes, 14 / 15 January 2013
Present: Tab Atkins, Steve Block, Shane Stephens, Douglas Stockwell, Brian Birtles
1. Status update
2. New time for meetings
3. Spring timing function
4. Interface options: reworking time sources
5. Interface options: with or without Timing object
6. Extensions to Document and Element interfaces
7. targetElement
 - spring timing function fiddle:
 - timing approach document
 - spring timing functions
 - more length support in polyfill (all units now supported)
 - rect, font-weight, integer support in polyfill
- TimeSources in polyfill
The next three meetings are as follows:
  Thurs Jan 17, 17:30 PST / Fri 18 Jan 12:30 AEDST / Fri 18 Jan 10:30 JST
  Tues Jan 22, 16:00 PST / Wed 23 Jan 11:00 AEDST / Wed 23 Jan 9:00 JST
  Thurs Jan 24, 17:30 PST / Fri 25 Jan 12:30 AEDST / Fri 25 Jan 10:30 JST
Following that:
  Week of 28 Jan: no meetings
  Week of 4 Feb: SVG F2F + CSS F2F, no Web Animations meetings
  Week of 11 Feb: Web Animations F2F -- decide meeting time going forward
Discussed spring timing functions.
Brian prefers a parameterisation in terms of an overshoot parameter plus perhaps one more: elasticity?
Shane: by "elasticity" you mean the number of bounces?
Brian: Not really sure. Perhaps more the amount of time it takes to settle.
Sydney team to investigate reparamterisation of physical spring systems in these terms.
Deferred until Friday
Possible APIs to investigate as data points: QML, raphael, CA, JQuery, android, DirectAnimation, WPF, d3, mathBox (, HTML
> Tab to check what Hixie thinks about the HTML MediaController API. Is it a pattern we should avoid or is it ok?
Deferred until Friday
I've added Element.animate but I wonder if we need other extensions to get the animations produced by content.
Use cases:
a) Provide debugging timeline of all active (i.e. running or scheduled to run in the future) animations
We could address this in two stages.
Version 1: Document.getActiveAnimations() -- gets the list of active animations and you just have to keep polling
> DO IT!
Version 2: A mutation observer-like API that lets you know when new animations are added / removed
> Shane to get input on event mechanism in specification
b) Remove all animations on an element before serializing
Element.getActiveAnimations()  -- returns a non-live sequence (array) of animations on the element so  you can cycle over them and call cancel on them all
> DO IT!
c) Make sure all animations on an element are complete before removing it from the DOM
e.g.   you might be doing an opacity fade and shrink transform on a UI widget  to indicate it is disappearing and you want to be sure both have  finished before removing it. In fact, you might have any number of CSS  transitions / animations defined on the item and you want to be sure  they're all finished.
You can register for animationend / transitionend events but how do you know when they're all done.
getActiveAnimations() would let you do this as follows:
elem.onanimationend = function(evt) {
    if ( === 0) {;
I'm  struggling to think of a real-world use case where you would want to  trigger an animation with CSS and then get at the *specific* Animation  object it generated and modify it. I'm sure they exist, but none come to  mind just yet.
Shane: Polyfilling advanced timing functions, etc. before CSS engines have caught up?
Brian: Maybe  a repeating animation that causes the text, "Bid now" to glow and  swell. You want to define it using CSS to save programming, but then as the auction draws near to an end, rather than setting another style, just use script to find the animation and set the playbackRate to 2. Doing so would avoid jumps but there's not much other advantage of using  script to do this--it could be done just by exposing animation-playback-rate to CSS and setting a class.
So, still not really compelling use cases for getting a specific animation back.
Should we add:
  Document.getActiveAnimations(), and
for now?
> Yes, sounds good. Need to think about whether or not 'active' is the most appropriate term. Agreed that in most use cases you probably want not only animations that are currently running (i.e. current time falls inside in the active interval) but also those scheduled to run in the future.
7. targetElement
Previously we talked about the possibility of either making clone() take a list of target elements or alternatively allowing Animations to refer to a list of target elements.
There seemed to be a preference for the latter?
If that's the case I think we could do the following:
* Rename targetElement to simply 'target'
* Add a note that AnimationTarget may represent other types in the future so content should test the type of arbitrary targets before using
(When you're explicitly creating the Animations yourself, obviously you don't need to test the type)
* Extend the AnimationTarget typedef to by a union such as:
  (Element or PseudoElement or sequence<Element>)
* Introduce a live list of nodes that matches a selector as a target  type? Maybe this will be already defined elsewhere in the Web platform  by then? Or maybe if you want to do that you should just use CSS?
Also discussed how the Animation would behave when targetting a list of elements. If you add an element to the list whilst the animation is running does it start from the beginning or catch up?
> Agreed it catches up. Everything is in strict synchronisation. If you want the behaviour where it starts from the beginning you need a different mechanism like CSS.
Next meeting: Thurs Jan 17, 17:30 PST / Fri 18 Jan 12:30 AEDST / Fri 18 Jan 10:30 JST @