[scroll-animations-1] Order of pause, setTimeline #5653
Labels
Comments
|
As a developer I think I would expect to set the timeline first, then pause, as the pause being applied in the same update as the new animation-timeline implies to me that it is meant to pause in the new timeline. |
|
In Gecko, we set the timeline first, and then handle play state. I also prefer to setting the timeline first. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<Rossen_> https://github.com//issues/5653#issuecomment-1271689506<dael> Rossen_: There's a link to the proposal https://github.com//issues/5653#issuecomment-1271689506 <dael> flackr: If you're using scroll linked animations with css it's possible to switch timeline and change place date in same update. Need a weel defined order <dael> flackr: chrome and gecko both set timeline first and then apply paused play state which is observable so what to define that way <dael> Rossen_: Any feedback? <dael> Rossen_: I see Boris from gecko seemed to have same preference <bramus> s/weel/well <dael> flackr: I also think it's more dev friendly because play state change feels it shoudl be related to new timeline <Rossen_> q? <dael> Rossen_: Objections? <dael> RESOLVED: Accept the proposal in https://github.com//issues/5653#issuecomment-1271689506 |
|
Updated in 214aa29 to say:
|
|
Looks good to me. |
graouts
added a commit
to graouts/WebKit
that referenced
this issue
Mar 4, 2025
…ynamic.tentative.html` is a failure https://bugs.webkit.org/show_bug.cgi?id=289085 Reviewed by NOBODY (OOPS!). The failing subtests in `scroll-animations/css/scroll-timeline-dynamic.tentative.html` were created 5 years ago and with the assumption that setting both `animation-play-state` and `animation-timeline` at once would first set the play state, and then the timeline. However, the spec issue that the test refers to [0] has since been addressed and the CSS Animations Level 2 specification now clearly says it's the opposite [1]: When multiple animation-* properties are set simultaneously, animation-timeline is updated first, so e.g. a change to animation-play-state applies to the simultaneously-applied timeline specified in animation-timeline. As a result we modify the WPT test to be in line with the current spec. Additionally, we add this spec text as a comment in the relevant implementation code and ensure to match it by placing the call to `syncStyleOriginatedTimeline()` up front under `CSSAnimation::syncPropertiesWithBackingAnimation()`. Note that this doesn't change behavior since it was already called prior to handling `animation-play-state` and the other properties that were handled prior to it had no bearing on the behavior of the procedure to set the timeline. [0] w3c/csswg-drafts#5653 [1] https://drafts.csswg.org/css-animations-2/#animation-timeline * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/scroll-timeline-dynamic.tentative-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/scroll-timeline-dynamic.tentative.html: * Source/WebCore/animation/CSSAnimation.cpp: (WebCore::CSSAnimation::syncPropertiesWithBackingAnimation):
|
The relevant WPT test is being updated in web-platform-tests/wpt#51098. |
webkit-commit-queue
pushed a commit
to graouts/WebKit
that referenced
this issue
Mar 4, 2025
…ynamic.tentative.html` is a failure https://bugs.webkit.org/show_bug.cgi?id=289085 Reviewed by Anne van Kesteren. The failing subtests in `scroll-animations/css/scroll-timeline-dynamic.tentative.html` were created 5 years ago and with the assumption that setting both `animation-play-state` and `animation-timeline` at once would first set the play state, and then the timeline. However, the spec issue that the test refers to [0] has since been addressed and the CSS Animations Level 2 specification now clearly says it's the opposite [1]: When multiple animation-* properties are set simultaneously, animation-timeline is updated first, so e.g. a change to animation-play-state applies to the simultaneously-applied timeline specified in animation-timeline. As a result we modify the WPT test to be in line with the current spec. Additionally, we add this spec text as a comment in the relevant implementation code and ensure to match it by placing the call to `syncStyleOriginatedTimeline()` up front under `CSSAnimation::syncPropertiesWithBackingAnimation()`. Note that this doesn't change behavior since it was already called prior to handling `animation-play-state` and the other properties that were handled prior to it had no bearing on the behavior of the procedure to set the timeline. [0] w3c/csswg-drafts#5653 [1] https://drafts.csswg.org/css-animations-2/#animation-timeline * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/scroll-timeline-dynamic.tentative-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/scroll-animations/css/scroll-timeline-dynamic.tentative.html: * Source/WebCore/animation/CSSAnimation.cpp: (WebCore::CSSAnimation::syncPropertiesWithBackingAnimation): Canonical link: https://commits.webkit.org/291573@main
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With
@scroll-timelineit's possible to switch the timeline and pause the animation at the "same" time. E.g. you can toggle a class like:.switch { animation-timeline: other; animation-play-state: paused; }.During setTimeline, we don't expect the current time to change if the animation is paused [1], but we do expect the current time to "reset" if the animation is playing, hence it matters which order we do things in:
Note a huge deal I think, we just need to specify what should happen.
cc @kevers-google @ogerchikov
The text was updated successfully, but these errors were encountered: