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

Reply via email to