[web-animations-1] Handling non-monotonically increasing timelines when setting the timeline of an animation. #5422
Labels
Comments
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 12, 2020
Mutability of the animation timeline is behind the feature flag for ScrollTimeline. The feature is marked as web-exposed, but with a no-op implementation if the feature flag is not set. With the patch, a number of the failing tests are now failing for different reasons: * Replaceable animations should consider all timelines when determining if an animation can be removed. Our current implementation only considers other animations on the same timeline when making the decision. Fixing these failures requires some refactoring, which is deferred to a followup CL. * Resetting the timeline cancels a running CSS animation or transition. Some refactoring is required to ensure that we properly compute the cancel time as it depends on the old timeline. Again, deferring to a followup CL. w3c/csswg-drafts#5159 w3c/csswg-drafts#5422 https://drafts.csswg.org/scroll-animations-1 https://www.chromestatus.com/feature/6752840701706240 Bug: 827626 Change-Id: I1fea09a80e8730694455c06b192cb9e068eb0c55
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Aug 20, 2020
Mutability of the animation timeline is behind the feature flag for ScrollTimeline. The feature is marked as web-exposed, but with a no-op implementation if the feature flag is not set. With the patch, a number of the failing tests are now failing for different reasons: * Replaceable animations should consider all timelines when determining if an animation can be removed. Our current implementation only considers other animations on the same timeline when making the decision. Fixing these failures requires some refactoring, which is deferred to a followup CL. * Resetting the timeline cancels a running CSS animation or transition. Some refactoring is required to ensure that we properly compute the cancel time as it depends on the old timeline. Again, deferring to a followup CL. w3c/csswg-drafts#5159 w3c/csswg-drafts#5422 https://drafts.csswg.org/scroll-animations-1 https://www.chromestatus.com/feature/6752840701706240 Bug: 827626 Change-Id: I1fea09a80e8730694455c06b192cb9e068eb0c55
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Sep 1, 2020
Mutability of the animation timeline is behind the feature flag for ScrollTimeline. The feature is marked as web-exposed, but with a no-op implementation if the feature flag is not set. With the patch, a number of the failing tests are now failing for different reasons: * Replaceable animations should consider all timelines when determining if an animation can be removed. Our current implementation only considers other animations on the same timeline when making the decision. Fixing these failures requires some refactoring, which is deferred to a followup CL. * Resetting the timeline cancels a running CSS animation or transition. Some refactoring is required to ensure that we properly compute the cancel time as it depends on the old timeline. Again, deferring to a followup CL. w3c/csswg-drafts#5159 w3c/csswg-drafts#5422 https://drafts.csswg.org/scroll-animations-1 https://www.chromestatus.com/feature/6752840701706240 Bug: 827626 Change-Id: I1fea09a80e8730694455c06b192cb9e068eb0c55
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Sep 2, 2020
Mutability of the animation timeline is behind the feature flag for ScrollTimeline. The feature is marked as web-exposed, but with a no-op implementation if the feature flag is not set. With the patch, a number of the failing tests are now failing for different reasons: * Replaceable animations should consider all timelines when determining if an animation can be removed. Our current implementation only considers other animations on the same timeline when making the decision. Fixing these failures requires some refactoring, which is deferred to a followup CL. * Resetting the timeline cancels a running CSS animation or transition. Some refactoring is required to ensure that we properly compute the cancel time as it depends on the old timeline. Again, deferring to a followup CL. w3c/csswg-drafts#5159 w3c/csswg-drafts#5422 https://drafts.csswg.org/scroll-animations-1 https://www.chromestatus.com/feature/6752840701706240 Bug: 827626 Change-Id: I1fea09a80e8730694455c06b192cb9e068eb0c55
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Sep 2, 2020
Mutability of the animation timeline is behind the feature flag for ScrollTimeline. The feature is marked as web-exposed, but with a no-op implementation if the feature flag is not set. With the patch, a number of the failing tests are now failing for different reasons: * Replaceable animations should consider all timelines when determining if an animation can be removed. Our current implementation only considers other animations on the same timeline when making the decision. Fixing these failures requires some refactoring, which is deferred to a followup CL. * Resetting the timeline cancels a running CSS animation or transition. Some refactoring is required to ensure that we properly compute the cancel time as it depends on the old timeline. Again, deferring to a followup CL. w3c/csswg-drafts#5159 w3c/csswg-drafts#5422 https://drafts.csswg.org/scroll-animations-1 https://www.chromestatus.com/feature/6752840701706240 Bug: 827626 Change-Id: I1fea09a80e8730694455c06b192cb9e068eb0c55
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Sep 3, 2020
Mutability of the animation timeline is behind the feature flag for ScrollTimeline. The feature is marked as web-exposed, but with a no-op implementation if the feature flag is not set. With the patch, a number of the failing tests are now failing for different reasons: * Replaceable animations should consider all timelines when determining if an animation can be removed. Our current implementation only considers other animations on the same timeline when making the decision. Fixing these failures requires some refactoring, which is deferred to a followup CL. * Resetting the timeline cancels a running CSS animation or transition. Some refactoring is required to ensure that we properly compute the cancel time as it depends on the old timeline. Again, deferring to a followup CL. w3c/csswg-drafts#5159 w3c/csswg-drafts#5422 https://drafts.csswg.org/scroll-animations-1 https://www.chromestatus.com/feature/6752840701706240 Bug: 827626 Change-Id: I1fea09a80e8730694455c06b192cb9e068eb0c55
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Sep 3, 2020
Mutability of the animation timeline is behind the feature flag for ScrollTimeline. The feature is marked as web-exposed, but with a no-op implementation if the feature flag is not set. The rationale for this setup is that we don't support conditionally readonly attributes in IDL. With the patch, a number of the failing tests are now failing for different reasons: * Replaceable animations should consider all timelines when determining if an animation can be removed. Our current implementation only considers other animations on the same timeline when making the decision. Fixing these failures requires some refactoring, which is deferred to a followup CL. * Resetting the timeline cancels a running CSS animation or transition. Some refactoring is required to ensure that we properly compute the cancel time as it depends on the old timeline. Again, deferring to a followup CL. w3c/csswg-drafts#5159 w3c/csswg-drafts#5422 https://drafts.csswg.org/scroll-animations-1 https://www.chromestatus.com/feature/6752840701706240 Bug: 827626 Change-Id: I1fea09a80e8730694455c06b192cb9e068eb0c55
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Sep 9, 2020
Mutability of the animation timeline is behind the feature flag for ScrollTimeline. The feature is marked as web-exposed, but with a no-op implementation if the feature flag is not set. The rationale for this setup is that we don't support conditionally readonly attributes in IDL. With the patch, a number of the failing tests are now failing for different reasons: * Replaceable animations should consider all timelines when determining if an animation can be removed. Our current implementation only considers other animations on the same timeline when making the decision. Fixing these failures requires some refactoring, which is deferred to a followup CL. * Resetting the timeline cancels a running CSS animation or transition. Some refactoring is required to ensure that we properly compute the cancel time as it depends on the old timeline. Again, deferring to a followup CL. w3c/csswg-drafts#5159 w3c/csswg-drafts#5422 https://drafts.csswg.org/scroll-animations-1 https://www.chromestatus.com/feature/6752840701706240 Bug: 827626 Change-Id: I1fea09a80e8730694455c06b192cb9e068eb0c55 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2324101 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Olga Gerchikov <gerchiko@microsoft.com> Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Commit-Queue: Kevin Ellis <kevers@chromium.org> Cr-Commit-Position: refs/heads/master@{#805371}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Sep 9, 2020
Mutability of the animation timeline is behind the feature flag for ScrollTimeline. The feature is marked as web-exposed, but with a no-op implementation if the feature flag is not set. The rationale for this setup is that we don't support conditionally readonly attributes in IDL. With the patch, a number of the failing tests are now failing for different reasons: * Replaceable animations should consider all timelines when determining if an animation can be removed. Our current implementation only considers other animations on the same timeline when making the decision. Fixing these failures requires some refactoring, which is deferred to a followup CL. * Resetting the timeline cancels a running CSS animation or transition. Some refactoring is required to ensure that we properly compute the cancel time as it depends on the old timeline. Again, deferring to a followup CL. w3c/csswg-drafts#5159 w3c/csswg-drafts#5422 https://drafts.csswg.org/scroll-animations-1 https://www.chromestatus.com/feature/6752840701706240 Bug: 827626 Change-Id: I1fea09a80e8730694455c06b192cb9e068eb0c55 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2324101 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Olga Gerchikov <gerchiko@microsoft.com> Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Commit-Queue: Kevin Ellis <kevers@chromium.org> Cr-Commit-Position: refs/heads/master@{#805371}
blueboxd
pushed a commit
to blueboxd/chromium-legacy
that referenced
this issue
Sep 9, 2020
Mutability of the animation timeline is behind the feature flag for ScrollTimeline. The feature is marked as web-exposed, but with a no-op implementation if the feature flag is not set. The rationale for this setup is that we don't support conditionally readonly attributes in IDL. With the patch, a number of the failing tests are now failing for different reasons: * Replaceable animations should consider all timelines when determining if an animation can be removed. Our current implementation only considers other animations on the same timeline when making the decision. Fixing these failures requires some refactoring, which is deferred to a followup CL. * Resetting the timeline cancels a running CSS animation or transition. Some refactoring is required to ensure that we properly compute the cancel time as it depends on the old timeline. Again, deferring to a followup CL. w3c/csswg-drafts#5159 w3c/csswg-drafts#5422 https://drafts.csswg.org/scroll-animations-1 https://www.chromestatus.com/feature/6752840701706240 Bug: 827626 Change-Id: I1fea09a80e8730694455c06b192cb9e068eb0c55 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2324101 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Olga Gerchikov <gerchiko@microsoft.com> Reviewed-by: Anders Hartvoll Ruud <andruud@chromium.org> Commit-Queue: Kevin Ellis <kevers@chromium.org> Cr-Commit-Position: refs/heads/master@{#805371}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The procedure for setting the timeline does not fully align with the expected behavior for scroll timelines. Notably:
https://drafts.csswg.org/web-animations-1/#setting-the-timeline
Presently we have logic in play and pause to handle specific requirements for non-monotonically increasing (scroll) timelines. The proposed behavior would ensure that the following two methods for starting a scroll linked animation produce the same effect:
const animation = elem.animate(...);
animation.timeline = scrollTimeline;
and
const animation = new Animation(..., scrollTimeline);
animation.play();
At present, Blink only supports the second option, but development is underway to support mutable timelines, which is required for supporting the CSS property 'animation-timeline'.
The text was updated successfully, but these errors were encountered: