W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2020

Re: [csswg-drafts] [web-animations-1] Add steps for transitioning to/from a scroll timeline. (#5423)

From: kevers-google via GitHub <sysbot+gh@w3.org>
Date: Mon, 24 Aug 2020 14:59:45 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-679178972-1598281183-sysbot+gh@w3.org>
Taking a step back to cover the options at a higher level, which should hopefully help us to reach consensus on which path to adopt.  Starting with some high level design considerations:
* Try to avoid unexpected jumps in the animation.
* Keep a running scroll-linked animation in sync with the scroll position.
* Ideally, limit the amount of special case logic.
* Seamlessly handle pending play state changes.
* Equivalent behavior between the following use cases:

const animation = new Animation(..., scrollTimeline);


const animation = element.animate();
animation.timeline = scrollTimeline;

* Store the previous value for current time before changing the timeline.
* Unconditionally, set current time to previous current time after changing the timeline.
* pros:
    * Prevent jumps when switching timeilnes.
* cons:
    * Potentially Introduces a phase-shift when switching to a scroll timeline.  In other words, the value for current time may be out of sync with the scroll position.  
    * Breaks one of the WPT tests, for transitioning between two document timelines with differing  originTimes.

I believe the phase shift is unexpected behavior especially when using scroll timelines via CSS rules and the animation-timeline property.  Nonetheless, including it here for discussion.

Option 2:
* Special handling for transitioning to/from a scroll timeline.
* Set start time to beginning or end depending on the sign of the playback rate.
* pros:
    * No phase shift.  Current time is in sync with the scroll position.
    * Introduces special casing, which makes the spec harder to conceptualize.
    * How do we handle paused or pause-pending animations? The tricky edge case here is when the new scroll timeline is inactive. Preserving current time might be our best option here, but we'll then need to handle synchronization once the animation becomes unpaused.

Option 3:
* Special handling for transitions to/from a scroll timeline.
* Set the start time when transitioning to a running/finished scroll timeline.
* Otherwise set current time to previous current time like in option 1.
* Update the play procedure to unconditionally update the start time if using a scroll timeline. Currently, only done if current time is unresolved.
* pros:
    * Avoids unnecessary jumps when an animation is paused.
    * Believe this aligns with our expected behavior for the animation-timeline property.
    * This also addresses the problem of pause + scroll + unpause.  Currently, this causes a phase shift.  Naturally, this conclusion is based on an assumption that we don't want to allow a phase shift.
* cons:
    * Now tweaking two procedures instead of one.

There may be other options to consider and would welcome any feedback.  Option 3 (my new preference) is not what is currently implemented in the pull request, but would like some feedback before proceeding with the next update.


GitHub Notification of comment by kevers-google
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/5423#issuecomment-679178972 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 24 August 2020 14:59:46 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:13 UTC