W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2019

Re: [csswg-drafts] [web-animations-1] Make animations become idle when they have an inactive timeline (#2066)

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 Dec 2019 23:17:05 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-567255509-1576711023-sysbot+gh@w3.org>
Thinking about the start time issue bit further:

* For a paused animation linked to a scroll timeline, making `play()` cause the animation to jump to the current position of the scroller seems fine for most cases. That is, the current Chromium implementation of setting `startTime` to 0 or null seems fine for most cses.
* However, we still need to allow setting the `startTime` to other values because:
  * At very least, we want to be able to seek an `Animation` without a timeline and if a null timeline and a scroll timeline are in the same class of timelines, that suggests we should be able to set the `currentTime` on an animation attached to a scroll timeline, which, in turn, implies being able to set the `startTime` to something other than zero.
  * Being able to seek a scroll-driven animation seems somewhat useful.
  * Having the `startTime` setter throw when setting any other value than zero or null while the animation is attached to a scroll timeline is odd.
  * When hot-swapping from a document timeline to a scroll timeline, presumably we want to preserve the `currentTime`, which also implies being able to set the `startTime` (this use case could use more careful thought, however).
  * (It would be nice to be able to set up a scroll-driven animation that runs at some offset from its scroll timeline by using `startTime` seems useful but preserving that offset could be hard.)
* The different classes of timelines needs more thought. If we think about a timeline based on a media element (e.g. `<video>`) it is generally both finite (except for the streaming case) and non-monotonic. In that sense, it is similar to the scroll timeline case. However, it differs in that if you hit `play()` on an animation bound to the `<video>` timeline, you probably want it to start at the current video time--or at least I believe there are use cases for both.

In some sense, we can already handle these different cases by, e.g. doing `anim.startTime = 0` instead of `anim.play()` but I suspect authors are going to reach for `anim.play()` first so we need to make that do something sensible.

GitHub Notification of comment by birtles
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2066#issuecomment-567255509 using your GitHub account
Received on Wednesday, 18 December 2019 23:17:06 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:57 UTC