- From: kevers-google via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Aug 2020 14:00:10 +0000
- To: public-css-archive@w3.org
One of the great things with the web animations API is that, for the most part, animations constructed via CSS behave consistently with animations created via JavaScript. Sure there is more control from JavaScript, but there is a common baseline. In fact, we can freely mix the two approaches by applying CSS style changes from JavaScript, or by fetching CSS animations via getAnimations. The primary goal with the proposed algorithm is to maintain a consistent and expected behavior between CSS and JavaScript animations.
By "existing procedure" I assume that you mean the one that is currently published in web-animations-1 and not the one in this pull request.
case 1: Transitioning from a document timeline to a scroll timeline
@keyframes fade-anim { ... }
@scroll-timeline timeline { ... }
.fade { animation: fade-anim ... }
.scrolling-animation { animation-timeline: timeline }
In this example, if an animation is created by adding the fade class and then later the animation is attached to a scrollbar via the scrolling-animation class we can wind up with some weird inconsistencies.
case 1a: animation is play-pending when scroll timeline is added.
The initial play procedure sets the hold time to zero; however, a scroll linked animation initializes start time and not hold time in the play procedure. This leaves us in an inconsistent state unless we rethink the play procedure to avoid special casing for scroll timelines.
case 1b: animation is pause-pending when the scroll timeline is added
The pause procedure initializes the hold time to zero; however, the same procedure initializes start time if run with a scroll timeline. Again this leaves us in an inconsistent state.
case 1c: animation is running when scroll timeline is added.
The animation jumps to an unexpected position when the scroll timeline is set.
case 1d: animation is paused when scroll timeline is added.
No jump when the timeline is set; however, once the animation resumes, it continues from the current position which is likely to be out of sync with the scroll position. It is unrealistic to expect that the scroll position will be at zero when the timelne is added.
case 1e: animation is idle when the scroll timeline is added.
This case works as expected.
The question may arise, "well why can't the developer simply avoid these cases by setting the timeline in the same frame where the animation starts?" One reason might be that the scroll-timeline attachment is deferred until content is loaded to avoid jank. The developer could inadvertently change the flow by querying style during the process of attaching the timeline (e.g. querying to determine the scroll range). From the implementation side, it should not matter if the timeline is passed into the animation constructor or immediately before/after play/pause.
case 2: CSS theme change triggering a change from one CSS scroll timeline to another.
Since the two timelines can have different values for the start and end properties, the scroll position can translate to different values of current time. The existing procedure does not accommodate this, and current time may become out of sync with the scroll position.
--
GitHub Notification of comment by kevers-google
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/5423#issuecomment-681967325 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 27 August 2020 14:00:12 UTC