[web-animations] Web Animations minutes, 5 June 2014

Web Animations minutes, 5 June 2014

Present: krit, doug, shans, birtles
Archived etherpad: 
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.12906

Agenda:

1. Name properties for AnimationNodes
2. Promises, promises, promises
3. Minifill & Maxifill
4. WD out the door
5. Zero-duration bugs


1. NAME PROPERTIES FOR ANIMATION NODES
======================================
(Shane)

Shane: Can we have animationNode.name that maps to element ids?
Brian: Maybe that is good to put into the API. And might be ok to make 
it public.

Brian: should defer how this works for SVG for now, because we haven't 
really designed how SVG interacts with CSS here. It may be that in the 
future that we allow animation-name to point to an SVG element and I'm 
not sure if that should use an ID reference or if it makes more sense to 
add a "name" property to animation elements.

Brian: Should it be on AnimationNode or AnimationEffect?

Doug:
var anim = new Animation(); ...
anim.name = 'my-gracious-animation';

Shane: Defer to next meeting after we get a chance to think about it.

Doug: We could put a note in the spec that we might consider using name 
in the future for this purpose (on AnimationNode, Player, Effect). That 
allows authors to start using it for their own purposes.

Brian: Oh, it's writeable? If it's writeable I would expect changes to 
name to do things like point to new effects. Putting on the effect might 
help.

Doug & Shane to think more about it.


2. PROMISES, PROMISES, PROMISES
===============================
(Shane)

Shane: We think we can get away without 'em

Background: There are a few situations where we have considered them.

One is when you call pause but the time on the main thread is different 
to the time on the compositor. So what do you do? Do you rewind the 
compositor to match the main thread? Do you fast-forward the main 
thread? Neither are particularly nice.

The proposal was to use a Promise that tells you when the pause has 
actually been performed and then you can see the pause time as the 
resolution of the Promise.

But this still leaves the question of what happens if you read current 
time while the Promise is outstanding.

Alternatively, what about making currentTime/startTime null/NaN during 
in the period while you are waiting to pause?

Further background: We also talked about using promises when you create 
a new animation which would be resolved when the animation actually 
rendered its first frame, i.e. actually started. The suggestion is that 
we possibly don't need that here but we can use the same null/NaN 
approach and add a promise later for all these sorts of use cases as needed.

Aside, startTime (since it's the effective start time) should be 
null/NaN when paused/held/starting etc.

Whenever startTime/currentTime is null/NaN, it should still be 
writeable. For example, if you're waiting for an animation to start you 
could force the startTime to a certain time rather than letting it be 
set when the animation is ready.

Need to consider what happens if you set startTime while paused however.

Brian: As a separate issue, a lot of authors are interested in having 
end-player promises. We currently use events since an animation can 
finish multiple times unlike Promises which are resolved once. However, 
there are use cases where this makes sense (e.g. where you *know* you're 
not going to rewind the animation and are just making a single-shot 
animation) and there is an expectation that you can do this based on 
jQuery etc.

Doug: Seems OK, but I'm worried that people might use it to chain. This 
is not a reliable way to do chaining.

Brian: So we might need to consider if player.finished should actually 
be a promise and if we should rename "finished" to something else (along 
with the finished event).

Doug: How about:
element.animate(...).when('finished').then(function() { ... });
element.animate(...).when('paused').then(function() { ... });
element.animate(...).when('started').then(function() { ... });

Shane: the promise could also be on 'done'.
element.animate(...).done.then(function() { ... });


3. MINIFILL & MAXIFILL
======================
(Shane)

We're going to start a polyfill rewrite

Minifill - Just the feature set we're working on implementing natively 
at present. Phase-1 includes both element.animate, Players, playback 
control, getAnimationPlayers etc.
Maxifill/Futurefill - The features we're yet to implement. Sits on top.


4. WD OUT THE DOOR (NEARLY)
===========================
(Brian)

WD ready to go any moment now: 
http://www.w3.org/TR/2014/WD-web-animations-20140605/


5. ZERO-DURATION BUGS
=====================
(Brian)

A few bugs I came across in implementing these algorithms:

* When calculating the directed time, d can be infinity which means d % 
2 is undefined (suggest defining it to be 0)
* If we have an animation of zero length with infinite iterations then 
after the animation has finished, the currentIteration member should be 
infinity. Can this be represented as an integer in the IDL (it can in 
ECMAScript but hey)
* Current iteration is wrong when we have a zero-duration animation (we 
always return 0?) or we always return ceil(iteration start + iteration 
count) - 1 ??

Doug: Reminds me of these tests: 
http://rawgit.com/dstockwell/blink/master/LayoutTests/animations/timing-model.html

Shane: These seem like sensible behaviours.

Shane & Doug to look at the Chrome implementation and see what we 
currently do.


Next meeting, Thurs 19 June 2014 07:00 UTC 07:00
   Local time: 
http://arewemeetingyet.com/UTC/2014-06-19/07:00/Web%20Animations

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

Received on Thursday, 5 June 2014 07:59:04 UTC