[scroll-animations] setting `animation-timeline` to a value that doesn't match a `scroll-timeline-name` behaves differently than setting `timeline` to `null` #48750
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:
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.
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.
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 matchingscroll-timeline-name: --timeline
declared anywhere.CSS Animations Level 2 in its
animation-timeline
section says:In WebKit, we take that last line to mean make the animation's timeline
null
and functionally similar to callinganimation.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
tonull
, 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.