- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 05 Oct 2022 17:35:09 +0000
- To: public-css-archive@w3.org
Concluding the discussion so far. The transition reaches a state with no active animations when the following is true: 1. None of the transition pseudo-elements have an animation in [paused](https://w3c.github.io/csswg-drafts/web-animations-1/#paused-play-state) or [running](https://w3c.github.io/csswg-drafts/web-animations-1/#running-play-state) state. 2. There are no events in [pending animation event queue](https://w3c.github.io/csswg-drafts/web-animations-1/#pending-animation-event-queue) associated with an animation on the transition pseudo-elements. I think this addresses @jakearchibald's [here](https://github.com/w3c/csswg-drafts/issues/7785#issuecomment-1256979379) since [clearing the queue happens after microtask checkpoint](https://drafts.csswg.org/web-animations-1/#update-animations-and-send-events:~:text=Let%20events%20to%20dispatch%20be%20a%20copy%20of%20doc%E2%80%99s%20pending%20animation%20event%20queue). I also propose we limit the animations considered in 1 to the ones using the Document timeline for now. For scroll-timeline for instance, looks like the animation will remain in running state as long as the scrollable element has overflow to scroll. Seems like this will become a foot-gun. We can start with treating these like rAF driven animations, where the developer decides when to consider them inactive. Based on the usage patterns we see, we can later add them to this automatic logic. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7785#issuecomment-1268731933 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 5 October 2022 17:35:11 UTC