- From: Jake Archibald via GitHub <sysbot+gh@w3.org>
- Date: Tue, 06 Oct 2020 08:08:40 +0000
- To: public-css-archive@w3.org
Ah, I see. I saw the task queuing and thought the algorithm was running off the main thread, and in turn I misinterpreted everything else. Sorry! > > The event and promise should happen at the 'same time' from the developer's perspective. Since event dispatch is synchronous, and promise callbacks are asynchronous, this means all event listeners should be called before any 'same' promise callbacks. I've asked for some clarification on this in the promises guide [w3ctag/promises-guide#71](https://github.com/w3ctag/promises-guide/issues/71). > > To ensure that, I think we'd need to somehow resolve the finished promises in the "update animations and send events" procedure. That sounds a little tricky to me and I wonder if it would be Web-compatible, but if someone wants to try, please do! The animation spec is already having to hack around the ordering by [creating a microtask checkpoint in step 3](https://drafts.csswg.org/web-animations/#update-animations-and-send-events). This is why I think the order is incorrect, as every spec that wants to follow this ordering will have to add a microtask checkpoint before event dispatch. Spec wise, it would involve adding the promise, value, and resolve/reject along with the event info in the event queue. I don't have a strong feeling in terms of web compatibility, but it'd be sad if web animation becomes an outlier in terms of event & promise ordering. -- GitHub Notification of comment by jakearchibald Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5582#issuecomment-704105434 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 October 2020 08:08:42 UTC