[web-anim] Web animations minutes, 13 February 2013

Web animations minutes, 13 February 2013

Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.e9QRyeowiu6/latest
Present: Dmitry, Doug, Shane, Steve, Brian

Agenda:
1. Play control continued
2. Reviewing time sources and SVG play control

1. PLAY CONTROL CONTINUED
=========================

Topics:
• 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 
don’t 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 = document.play(timedItem);
var player = document.timeline.play(timedItem);

Dmitry points out that these don’t 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 issue—is returning 
a Player more consistent?

Decision: we're going to go with approach 3 and allow the createPlayer 
constructor to start the animation.

2. REVIEWING TIME SOURCES
=========================

Issues:
• 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 control—at 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 document.play(anim) or 
document.timeline.play(anim) 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* we want to apply SVG animations via CSS it might look like this:

SVG:
<par id="button-thing">
   <animate attributeName="yer">
</par>

CSS:
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. This seems 
better.

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.play() - document timeline
   SVGSVGElement.timeline.play() - local (SVG) timeline
   Element.animate() - which one? Default is local timeline for SVG 
namespace elements and document timeline for others?
   document.createPlayer() - document timeline
   SVGSVGElement.createPlayer() - local (SVG) timeline

How would the interface look?

SVG1.1:
   SVGSVGElement
     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
     play();
     pause();
     unpause();
     currentTime;
     playbackRate;
     startTime;
     reverse();

That's pretty ugly to have both currentTime and getCurrentTime and 
setCurrentTime.

Better to just extend SVGSVGElement with the additional features of 
Player without making it implement the interface.

i.e.
   SVGSVGElement
     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
     playbackRate;
     startTime;
     reverse();

Comparing this to Document:
   Document
     attribute Timeline timeline;
     Player createPlayer();

The arrangement is consistent

CSS animations on a custom timeline such as the spinner use case? Maybe 
it's ok for animation-timeline to be per-animation?


Next meeting: Thurs 14 Feb 9:00 AEDST @ Google Sydney

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

Received on Wednesday, 13 February 2013 22:50:59 UTC