W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2018

[csswg-drafts] [web-animations] Setting `playbackRate` should probably do a compensatory seek after all

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Fri, 02 Feb 2018 20:16:00 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-294010370-1517602559-sysbot+gh@w3.org>
birtles has just created a new issue for https://github.com/w3c/csswg-drafts:

== [web-animations] Setting `playbackRate` should probably do a compensatory seek after all ==
In writing the last few tests for the asynchronous playback rate changes (#2059) I noticed an oddity:

```js
const animation = div.animate(...);
animation.currentTime = 100 * 1000;
await animation.ready;
animation.playbackRate = 2;
// animation.currentTime =~ 200 * 1000;
```

However:

```js
const animation = div.animate(...);
animation.currentTime = 100 * 1000;
animation.playbackRate = 2;
// animation.currentTime =~ 100 * 1000;
```

The reason is that in the first example the current time is calculated from the start time so changing the playback rate makes it jump. In the second example the current time is calculated from the hold time (the start time is unresolved at this point) so updating the playback rate does not effect the current time.

That inconsistency seems really undesirable. I suspect we want to make setting the playback rate do a compensatory seek after all. That means that doing `anim.playbackRate = 2` and `anim.updatePlaybackRate(2)` are quite close in behavior and authors may accidentally doing the former when they really want the latter but I can't think of anything better. We could just make `playbackRate` read-only but that's likely to break content.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2266 using your GitHub account
Received on Friday, 2 February 2018 20:16:04 UTC

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