- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Dec 2019 03:49:13 +0000
- To: public-css-archive@w3.org
> I don't see any text in the Web Animations spec or the CSS Transitions and CSS Animations specs that specifies that, if I understand correctly, events of type `AnimationPlaybackEvent` sort before events of type `TransitionEvent` or `AnimationEvent` for otherwise matching conditions. Yeah, in Firefox the playback event is queued first before the CSS animation event. Then because the events have the same scheduled event time and are sorted using a stable sort, they remain in that order. Per spec, the `AnimationPlaybackEvent` is queued synchronously as part of the [cancel an animation steps](https://drafts.csswg.org/web-animations-1/#cancel-an-animation) with a _scheduled event time_ of _timeline time_. The timing of the `animationcancel` event is not actually specified for the case of a synchronous cancel. It is, however, for an asynchronous one (e.g. via updating style) as per the [event dispatch](https://drafts.csswg.org/css-animations-2/#event-dispatch) section in CSS animations 2. That section refers to _sampling_ but that definition has been removed so we need to update that. It also doesn't define the _scheduled event time_ but presumably it is also the _timeline time_ when the animation was canceled. So that would still produce the same result of the CSS animation event showing up after the playback event. So I suppose the following changes are needed: * Define that the cancel procedure synchronously queues CSS animation/transition events too after the playback events. * Define the scheduled event time for these events. * Fix the reference to sampling to whatever the current concept is. -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4553#issuecomment-561464430 using your GitHub account
Received on Wednesday, 4 December 2019 03:49:16 UTC