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
