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

Web Animations minutes, 19 June 2014

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

Agenda:

1. Should a zero-duration repeating infinitely actually go forever?
2. Making finished a Promise?
3. Really return only the current animations?
4. Other TAG feedback


1. SHOULD A ZERO-DURATION REPEATING INFINITELY ACTUALLY GO FOREVER?
===================================================================
(Brian)

Currently we say the active duration of a zero-second animation that 
repeats forever is zero. However, it might actually be less 
discontinuous somehow if we said it goes forever.

All: Or maybe undefined? As in activeDuration = NaN etc.

In practical terms, if you have a green div, and you animate it from 
red->blue over 0s infinite times and it has a forwards fill, after the 
animation has started, do you see red, blue or green?

Three possible behaviors:

A) activeDuration = 0 (currently specced) --> blue
B) activeDuration = Infinity --> red?
C) activeDuration = NaN and the animation is in a kind of invalid state 
where it doesn't apply its result, doesn't dispatch events etc. --> green

Some questions from Brian:
* would CSS or SVG start events fire? Brian thinks probably not, Shane 
thinks he probably agrees
* what happens with subsequent animations in a sequence? Shane's 
suggestion: startTime = NaN.

Perhaps B is preferable because C means a lot of extra checks for NaN in 
different places.
Shane: yeah, let's go B. Sequence groups also introduce weirdness.

General feeling that this is quite an edge case and we can probably 
revise this behavior later if need be but for now B seems slightly more 
intuitive.


2. MAKING FINISHED A PROMISE?
=============================
(Brian)

https://github.com/w3ctag/promises-guide
^ Seems like it might not be so bad

Oh, I just noticed the TAG have made this an explicit request:
https://github.com/w3ctag/spec-reviews/commit/b5e0a9893e3d2ae9b0893324c616c2d7e0f041e5

On further consideration, I wonder how important the finished event is. 
But are there compatibility issues?

Shane:
from the TAG request:
+ap3.play();
+Promise.all([ap1.play(), ap2.play()]).then(() => {
+    setUpUINowThat1And2HaveStoppedMovingAround();
+    ap3.finished.then(() => {
+        completeAllUISetupNowThatEverythingIsStill();
+    });
+});

why aren't ap1 and ap2 already playing? This is more likely:

ap3.play();
document.timeline.play(new AnimationGroup([a1, a2])).then(() => {
     setUpUINowThat1And2HaveStoppedMovingAround();
     ap3.finished.then(() => {
         completeAllUISetupNowThatEverythingIsStill();
     });
});

Brian: I think this comes back to the other issue there about making 
AnimationPlayers constructible and not having timeline.play do both 
construction and starting.

ACTION: Shane to talk to the TAG about spending some face-to-face time 
discussing the best way to deal with this (and the play method issue).


3. REALLY RETURN ONLY THE CURRENT ANIMATIONS?
=============================================
(Brian)

One version of the TAG feedback questioned whether we really want to 
return only the current animations. I wonder about this too. It seems 
useful to return all the animations.

For example, if an element is translated to the side due to an animation 
doing a forwards fill, as a developer I'd like to be able to debug why 
it's over there.

Is there some way we can provide this and still deal with the case where 
a developer fires off a new animation with a forwards fill targeting the 
same element every second?

Shane's proposal:
Formalize and provide access to 'collapsed' or 'summarized' players that 
can then be cancelled. This could perhaps be as simple as a per-element 
property map. We could call it the player graveyard!

Brian: I'd want it to have the word 'fill' in the name somewhere, to 
represent the fact that this is animations that have run in the past but 
are still filling.

Shane: the player fill bone yard.

ACTION: Shane to prepare an API proposal for this. He probably won't 
call it the graveyard.


4. OTHER TAG FEEDBACK
=====================
(Brian)

https://github.com/w3ctag/spec-reviews/blob/master/2013/10/Web%20Animations.md

In particular, keen to work on computed timing soon.

Talked about this a bit here:
http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0082.html

Probably we prefer AnimationNode.computedTiming from the options 
discussed there since it's not particularly useful to share 
AnimationNodes since they refer to specific elements.


Next meeting, Thurs 3 July 2014 07:00 UTC 07:00
   Local time: 
http://arewemeetingyet.com/UTC/2014-07-03/07:00/Web%20Animations

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

Received on Thursday, 19 June 2014 23:51:06 UTC