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

[csswg-drafts] [scroll-animations] Limit start time of progress-based finite timeline linked animations to 0 (#4899)

From: Olga Gerchikov via GitHub <sysbot+gh@w3.org>
Date: Tue, 24 Mar 2020 17:49:17 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-587160655-1585072156-sysbot+gh@w3.org>
ogerchikov has just created a new issue for https://github.com/w3c/csswg-drafts:

== [scroll-animations] Limit start time of progress-based finite timeline linked animations to 0 ==
### Problem

In attempt to maintain web animations spec unmodified to support scroll animations, we introduced behaviors that are hard to rationalize. Specifically web animation APIs, such as setting current time, playback rate or unpause, adjust animation [start time](https://drafts.csswg.org/web-animations/#start-time) with a goal to preserve animation [current time](https://drafts.csswg.org/web-animations/#current-time). This works fine for time based animations since the time is unlimited. However, scroll animations which, based on #4862, can be classified as progress linked animations, as a result of changing start time, get their progress disconnected from the progress of the timeline they are attached to. The behavior observed in these situations is that effect progress is out of sync with the scroll and the effect itself is not fully accomplished.

In addition, the need to preserve start time significantly complicates specing for handling inactive timelines (#2066).

### Proposal

Limit [start time](https://drafts.csswg.org/web-animations/#start-time) of progress-based finite timeline linked animations to 0.

This involves disallowing changing [currentTime](https://drafts.csswg.org/web-animations/#setting-the-current-time-of-an-animation), [startTime ](https://drafts.csswg.org/web-animations/#setting-the-start-time-of-an-animation) of playing animations, only the [currentTime ](https://drafts.csswg.org/web-animations/#hold-time) of paused animations can be changed. Behaviors such as unpause or setting playback rate will cause a jump to the animation effect to stay in sync with the timeline progress.

The real question here is if there are any use cases that require start time to be other than 0. In other words is there a practical reason, besides spec compat,  for handling start time unmodified for progress based animations.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4899 using your GitHub account
Received on Tuesday, 24 March 2020 17:49:20 UTC

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