- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Aug 2018 02:21:52 +0000
- To: public-css-archive@w3.org
Yes, that's correct, but `getAnimations()` won't be shipping in any browser for some time yet. Until that ships, there's no way to detect currently running transitions. You have to detect them as they are triggered using `transitionrun`. I suspect that for your library it depends if you expect callers to call `waitForElementTransition` before or after transitions are generated. In the sample code there, it is being called _before_ transitions are generated (since `classList.add()` doesn't trigger a style flush). In that case you'd wait for the next animation frame, depending on where in the event loop `waitForElementTransition` is called possibly wait another animation frame so that style is updated, then if there there's no `transitionrun` event fired for the element, resolve the Promise at that point. Alternatively, you could flush style inside `waitForElementTransition` and then spin the event loop to check for a `transitionrun` event. If you want callers to be able to call `waitForElementTransition` _after_ transitions are generated then you'll probably need to do global bookkeeping (listening to `transitionrun`, `transitionend`, and `transitioncancel` events on the root element and tracking which elements have running transitions there). (For what it's worth, using timeouts to deal with `transitionend` events not firing is something we used to do in Firefox OS and became the motivating force for adding `transitioncancel` and `transitionrun` to the spec.) -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3043#issuecomment-415260345 using your GitHub account
Received on Thursday, 23 August 2018 02:21:53 UTC