- From: kevers-google via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Aug 2020 13:08:29 +0000
- To: public-css-archive@w3.org
Using the term "phase shift" to indicate the progress getting out of sync with the scroll position, being either ahead or behind the scroll position by a fixed amount if the start time is not adjusted. Yes both option 2 and 3 have special casing for scroll timelines, which I should have listed under cons for option 3. In fact, for option 3, it's in 2 methods (setTimeline and play). The main difference between options 2 and 3 in terms of observable behavior is in the handling of pause/unpause. In option 2, we adjust current time to align with the scroll position when changing the timeline for either a playing or paused animation. With option 3, setting the timeline of a paused animation does not trigger a jump to sync with the scroll position. Instead, it is deferred until we resume playing the animation. A potential gotcha with option 2 is when setting the timeline of a paused animation when the new scroll timeline is inactive. In this case, we don't know what the hold time should be set to in order to align with the scroll position once the timeline becomes active once again. Deferring the decision until play resolves the issue, since even if the timeline remains inactive we know whether start should be set to 0 or effect end. This awkward edge case with option 2 is the main reason for my shift towards option 3 as a preference. -- GitHub Notification of comment by kevers-google Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/5423#issuecomment-680014045 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 25 August 2020 13:08:30 UTC