search

web-platform-tests / wpt

Test suites for Web platform specs — including WHATWG, W3C, and others
https://web-platform-tests.org/
Other
4.99k stars 3.1k forks source link

[scroll-animations] setting `animation-timeline` to a value that doesn't match a `scroll-timeline-name` behaves differently than setting `timeline` to `null` #48750

Open graouts opened 5 days ago

graouts commented 5 days ago

I've been looking at making the "Reverse animation direction" subtest of scroll-animations/css/scroll-timeline-dynamic.tentative.html and I am puzzled about the expectation in the start of the test:

https://github.com/web-platform-tests/wpt/blob/21f732681e159d14e24b0a81f1dbcd578130bbca/scroll-animations/css/scroll-timeline-dynamic.tentative.html#L200-L206

Here the idea is to make the animation inactive by disassociating it from its timeline, by default up to this point the document timeline. At the point where animation-timeline is set to --timeline, the --timeline value cannot be resolved since there is no matching scroll-timeline-name: --timeline declared anywhere.

CSS Animations Level 2 in its animation-timeline section says:

<dashed-ident>

If a named scroll progress timeline or view progress timeline is in scope on this element, use the referenced timeline as defined in Scroll-driven Animations §  Declaring a Named Timeline’s Scope: the timeline-scope property.

Otherwise the animation is not associated with a timeline.

In WebKit, we take that last line to mean make the animation's timeline null and functionally similar to calling animation.timeline = null via the JavaScript API. But Chrome seems to introduce a subtle difference because it still has behavior that is similar to that of an animation associated with a progress-based timeline. Specifically, it looks like it auto-aligns the start time to set a value of 0% after a couple of frames.

Meanwhile if the test was to be modified to use the JavaScript API to set timeline to null, the outcome is different because the start time remains unresolved and the current time will resolve to 0.

I can understand the rationale used here as in animation-timeline was used so we likely are trying to create a progress-based animation but I'm not sure there is a specification to support this.

I'm not sure how else to realize the first assertion in that test besides not creating the animation until after the first assertion assert_width(element, '0px'), or simply removing it.

graouts commented 5 days ago

Cc @andruud who appears to be the author of the test, but also @flackr and @kevers-google who are knowledgeable in this area.