Server Notice:


Public Pad Latest text of pad bXuPDFJfYh Saved Feb 13, 2013

Meeting 45
Web animations minutes, 13 February 2013 
Present: Dmitry, Doug, Shane, Steve, Brian
1. Play control continued
2. Reviewing time sources and SVG play control
3. getCurrentAnimations()
4. Timing
Deciding between approach 2 and approach 3
Discussed with Elliott Sprehn: constructors with side effects. Apparently there is a trend in the Web platform to have objects that dont require an explicit play action but which are simple enough that the constructor kick-starts the action.
For the case of animations this suggests that the player constructor also plays the animation.
var player = document.createPlayer(timedItem); // i.e. this is totally legit
Do we still need:
var player =;
var player =;
Dmitry points out that these dont make it obvious that something is returned.
So our two approaches are:
element.animate({top: '100px'}, 2); // returns the animation (?)
document.createPlayer(new Animation(element, {top: '100px'}, 2)); // returns the player
What does element.animate() return?
Make it return Animation for now and mark it as an issueis returning a Player more consistent?
Decision: we're going to go with approach 3 and allow the createPlayer constructor to start the animation.
What is time zero for the document
What is the type of the document timeline
How does SVG work
SVG introduces the interesting situation that animations start on SVGLoad of the outermost <svg> element in a given fragment. Also, play control (pause/unpause/seek) is available on this outermost <svg> element. At the same time, we think it is desirable to be able to pause/seek top-level timed items inside each fragment. As such, there are two levels of play controlat the outermost <svg> element and at any non-nested <animate>, <set> etc.
This suggests a model where SVG has its own timeline and also its own play control (Player).
This raises the question of timelines and time sources. We wonder if there is actually a need of time sources at all. Instead we could just have a number of timelines.
Firstly, there is the document timeline. It has a zero time when the document onload event is fired. If CSS allows animations to be started at an absolute time then this would be related to this document timeline. e.g.
  animation-start-time: 2s; /* 2s since the document onload */
When you start animations using or it operates on this default document timeline.
However, it is also useful to be able to have animations run *before* the document onload such as for spinners to show while the document is loading or for streaming SVG. These could, perhaps, be represented on a separate timeline. For example, define the start timeline that has its zero time when the document finishes parsing / DOMContentLoaded is fired. Then you could do:
  animation-name: spinner;
  animation-timeline: start;
There's no way to synchronise animations on the start timeline with the default (onload) timeline since we won't expose a global clock (at least not initially) but we could provide conversion methods on the timelines to translate between timespaces for manual synchronising.
Why not expose a global clock? The main issue is that each timeline should be monotonically increasing. Breaking this assumption prevents a lot of optimisations from working and generally breaks things. So that's why we can't just expose wallclock time as a global clock. If you make sure the global clock is monotonically increasing then it will divert from wallclock time whenever the system clock is changed. Better to just provide a method to convert from wallclock time to a timeline's time.
As for the streaming use case, this could be realised by a custom timeline. Basically you'd create the custom timeline and then, at some time, say, "start now" and it effectively records that moment as the zero time. Then you can line up animations etc. on that custom timeline.
So how does SVG look now? Probably SVG too has one of these timelines for each <svg> document fragment. But this timeline also probably implements the Player interface.
But then how do you synchronise SVG animations with CSS animations etc.?
*If*, *if* we want to apply SVG animations via CSS it might look like this:
<par id="button-thing">
  <animate attributeName="yer">
div.button {
  animation-name: button-thing;
If the target is HTML, then the animation will run on the document timeline. If the target is SVG, it will run on the timeline of the SVG fragment it's part of. This is overrideable using 'animation-timeline'.
As for applying CSS animations to SVG, again, if the target is SVG, the animation runs in the SVG timeline?? Including following the pause state of that timeline?? Is that what you want? Or do you want CSS animations to never be paused in this way since they are probably UI effects?
Certainly, for CSS transitions we never want to pause them, so they should always run in the document timeline (which can't be paused). For CSS animations should we also run them (by default) in the document timeline? If you really want them to line up with SVG animations you have 'animation-timeline: svg'; ?
So then, the rule for applying an animation to a target using animation-name would be:
1. If animation-timeline is set, use that
2. Otherwise, if animation-name points to @keyframe -> use document timeline
Otherwise, animation-name points to an SVG definition.
3. If the target element is not in the SVG namespace use the document timeline
4. Otherwise, use the SVG timeline
Or we could just make animation-timeline default to 'default'. I.e. all animations referred to by animation-name run on the default document timeline unless animation-timeline was set to something else.
But wait, 'animation-timeline' here is defined per element. That's not what you want. It's conceivable to have multiple animations targetting an element that operate in different timelines.
But nor do you want animation-timeline to be per animation since you should be able to re-use an animation definition on different timelines. You really want this to be defined per application of an animation. That is, the combination of element and animation.
So let's just skip animation-timeline for now and say any animation applied with animation-name runs on the document timeline.
You can still apply SVG-defined animations such that they apply on the document timeline by using animation-name: #svg-ref.
You could apply CSS-defined animations in the SVG timeline using <animate name="keyframes-name-ref">?
As for scripted animations, how do you choose? - document timeline. - local timeline. Element.animate() - which one? Default is local timeline for SVG namespace elements and document timeline for others? document.createPlayer()?
    void pauseAnimations();
    void unpauseAnimations();
    boolean animationsPaused();
    float getCurrentTime();
    void setCurrentTime(in float seconds);
    SVGLength createSVGLength();
    SVGAngle createSVGAngle();
We will make this:
  SVGSVGElement implements Player
     attribute Timeline timeline;
     Player createPlayer(); // Creates a player that operates in the SVG timeline
     // Already on SVGSVGElement
    void pauseAnimations();
    void unpauseAnimations();
    boolean animationsPaused();
    float getCurrentTime();
    void setCurrentTime(in float seconds);
     // Player inherited members/methods
Better to just extend SVGSVGElement with the additional features of Player without making it implement the interface.
     attribute Timeline timeline;
     Player createPlayer(); // Creates a player that operates in the SVG timeline
     // Already on SVGSVGElement
    void pauseAnimations();
    void unpauseAnimations();
    boolean animationsPaused();
    float getCurrentTime();
    void setCurrentTime(in float seconds);
     // New stuff to provide Player behaviour
Comparing this to Document:
    attribute Timeline timeline;
    Player createPlayer();
CSS animations on a custom timeline such as the spinner use case? Maybe it's ok for animation-timeline to be per-animation?