- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 05 Jun 2014 16:58:33 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
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