On Tue, Jun 30, 2015 at 3:59 PM Brian Birtles <[email protected]> wrote:
> 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. > This synchronous queuing behavior for finish/cancel seems reasonable. > (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().) > +1 > > Best regards, > > Brian > >
