- From: Antoine Quint via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Nov 2024 17:43:07 +0000
- To: public-css-archive@w3.org
graouts has just created a new issue for https://github.com/w3c/csswg-drafts: == [scroll-animations] Relevance of scroll-driven animations == I’m trying to work out what in the relevant specs makes this simple code behave differently in Chrome and Safari*: ```html <html> <body style="height: 10000px"> <script> const target = document.body.appendChild(document.createElement("div")); const timeline = new ScrollTimeline({ source: document.documentElement }); const animation = target.animate({ marginLeft: "100px" }, { timeline }); </script> </body> </html> ``` In Chrome, calling `target.getAnimations()` immediately returns the animation. In Safari, an animation frame needs to run for the animation’s start time to auto-align and only then does calling `target.getAnimations()` return the animation. I’m puzzled how an animation with an unresolved start time, which is the case for this animation until its start time is auto-aligned, can be considered relevant. But this is a recurring problem in Safari and shows up in a host of WPT tests. It’s almost as if Chrome expected the definition of a [relevant animation](https://drafts.csswg.org/web-animations-1/#relevant-animations-section) to have a provision that if the animation is associated with a progress-based timeline, it’s relevant (or [current](https://drafts.csswg.org/web-animations-1/#current), or [in effect](https://drafts.csswg.org/web-animations-1/#in-effect)). \* [Safari Technology Preview](https://developer.apple.com/safari/resources/) 207 with the "Scroll-driven Animations" flag enabled in the “Settings…" → "Feature Flags” panel. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11223 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 November 2024 17:43:08 UTC