- 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