- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 30 Jun 2015 14:58:58 +0900
- To: "public-fx@w3.org" <public-fx@w3.org>
On 2015/06/30 13:21, Brian Birtles wrote: > Hi, > > I'm currently speccing finish/cancel events for animations and I think > it makes sense to dispatch finish events and also update the finished > promise in a separate task. I was thinking of applying similar handling to the cancel event including the part where we cancel a pending finished promise. However, a consequence of this handling is it means that in the following case: anim.finish(); anim.currentTime = 0; the finished promise won't resolve. Nor will any finish event fire. Likewise, if you say: anim.finish(); anim.cancel(); anim.currentTime = 0; The finished promise won't fulfill or reject. Nor will the finish or cancel event fire. Is that weird? I wonder if we the following behavior is more intuitive: 1. cancel() queues event dispatch / promise rejection synchronously such that calling cancel() always triggers a cancel event unless the animation is already idle. 2. finish() likewise queues event dispatch / promise resolution synchronously unlike simply setting the currentTime. (3. A timeline going inactive should cause us to update the hold time of any animation watching it. This is consistent with what happens when we set animation.timeline = null and means the only time we ever transition to the idle state is from a call to cancel().) Best regards, Brian
Received on Tuesday, 30 June 2015 05:59:21 UTC