[web-animations] Web Animations minutes, 14 Feb 2015

Web Animations minutes, 14 Feb 2015

Present: Doug, Shane, Brian
Archived etherpad: 
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.32354

Agenda:
1. What is the set of animations returned from getAnimationPlayers()?
2. play(), pause etc. and returning Promises
3. Renaming "time fraction" to "progress" something?
4. Animation end behavior
5. Naming
6. List interfaces
7. What's missing from level 1 for doing a good polyfill of groups?
8. Deferring custom effects from level 1
9. Allowing animations to repeat
10. Making default timing be "ease"?
11. Is composite add part of level 1?


1. WHAT IS THE SET OF ANIMATIONS RETURNED FROM getAnimationPlayers()?
=====================================================================

We didn't resolve this last time. Need to work this out.

CSS Animations are (might be) special, we might consider returning them 
as long as their name is in animation-name.

For the dev-tools use case, may need an API in future to capture 
animations as they start. The trouble is animations are often very 
subtle, short-lived effects so it can be hard to "catch" them if the API 
doesn't return them once they have finished playing.

 From one point of view, returning finished non-filling CSS Animations 
is consistent with style. But from another point of view, doing so is 
inconsistent with the behaviour for script-generated animations.

For now, we might just continue to *not* return CSS Animations that are 
not filling forwards and rely on a future API to capture animations as 
they start.


2. play(), pause etc. AND RETURNING PROMISES
============================================

Background is this thread: 
https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0026.html

Need to revisit this:
- Have a single promise of split them up?
- Have start() which returns a promise
   -> Further discussion: start vs finish? resume()? unpause()?

Proposal:

Two primitive operations
   pause() - pauses, returns ready promise (pause-ready promise?)
   resume() - unpauses, no seeking; returns ready promise (play-ready 
promise?)
     If there is no start time / hold time blocks until one is set?

Two operations built on top of that:
   start() - seeks to start, unpauses, returns ready promise (play-ready 
promise? start-ready promise?)
      i.e. seek + resume();
   finish() - seeks to end, unpauses, returns ready promise?
      i.e. seek + resume();
      the unpausing is important because it ensures calling finish() 
results in the play state becoming "finished"

Issue: Should finish() unpause? Some people think it shouldn't.

Two more operations built on top of that:
   play() - seeks if finished/idle, unpauses, returns finished promise
      i.e. seek + resume()
   reverse() - flips playbackRate; then does play()

After discussion, the set of operations seems reasonable. The only 
contentious part was whether finish() should unpause. Agreed to make it 
unpause for now but add an issue about this.

Discussed whether these methods should return promises or not, and, if 
they do, should there be one ready promise or more? For example, if you 
call play() and get back a promise, but call pause() before the play() 
takes effect (i.e. before rendering the first frame) should the 
originally returned promise reject? Or should it wait until the pause() 
has completed and then resolve normally?

 > Shane and Doug to think about this more.


3. RENAMING "TIME FRACTION" TO "PROGRESS" SOMETHING?
====================================================

To match GSAP and other common usage

-> Probably more intuitive


4. ANIMATION END BEHAVIOR
=========================

See: https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0048.html

Animation end behavior:

-> Shane to send proposal to list next week for "triggered fill"


5. NAMING
=========

Some resistance to GroupEffect

Alternatives:
   GroupedEffect
   EffectGroup
   CompositeEffect?
   ComposedEffect?
   CombinedEffect?
   MultiEffect?

Also, instead of KeyframeEffect some other suggestions have been:
   PropertyEffect
   TweenEffect

Looking at other APIs

QML:
   Animation
     ParallelAnimation
     SequenceAnimation
     PropertyAnimation
     PauseAnimation
   PropertyAction
   ScriptAction

CA
   CAAnimation
     CAGroupAnimation
     CAPropertyAnimation
       CAKeyframeAnimation

Android
   Animator
     AnimatorSet
     ValueAnimator

MathBox
   Animator
   Animation

After much discussion, agreed KeyframeEffect is probably best. Not sure 
what to call groups, probably GroupEffect and SequenceEffect but we 
don't need to lock this down until level 2.


6. LIST INTERFACES
==================

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682

interface Animatable {
   readonly attribute FrozenArray<Animation> animations;
}

Proposal for keyframes (in order to support sharing):
- define separate getter / setter for the 'frames' attribute
- getter returns a KeyframeList object which is basically an iterable 
wrapper for a list of keyframes that is shareable
- KeyframeList also has a ctor
- setter takes a union of (sequence<Keyframe> or object or KeyframeList) 
where object is the special { opacity: [ 0, 0.2, 1 ] }-style syntax

WebIDL doesn't support this yet, but should eventually.


7. WHAT'S MISSING FROM LEVEL 1 FOR DOING A GOOD POLYFILL OF GROUPS?
===================================================================

* iterationDelay
* stacked timing functions
* control of where an animation is playing -- main thread or compositor

ACTION: Shane to write these up and send to list.

We'll consider putting these into a Level 2 spec if they are well received.


8. DEFERRING CUSTOM EFFECTS FROM LEVEL 1
========================================

Do it. It should also probably take the form of an 'onsample' callback 
in parallel to any other specified effect.


9. ALLOWING ANIMATIONS TO REPEAT
================================

It seems like causing an animation to repeat indefinitely should be 
possible from the 'player'. e.g. it should be possible to take a CSS 
animation and re-run it automatically without having to clone the 
'animation' and then change its 'iterations' member. You can already 
re-run it, change its speed etc., why not also make it possible to loop 
it (without, e.g. waiting on the 'finished' event and then calling play())

In a future level we might add some kind of 'multi-player' that has 
multiple start times, possibly even infinitely repeating ones. This can 
maybe work instead of the iteration-delay.


10. MAKING DEFAULT TIMING BE "EASE"?
====================================

Thread starting: 
https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0051.html

Concern with making "ease" the default on *either* the Effect *or* the 
keyframes, is that you have to undo the "ease" if you want to change 
easing elsewhere.


11. IS COMPOSITE ADD PART OF LEVEL 1?
=====================================

Yes.


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

Received on Saturday, 14 February 2015 07:25:07 UTC