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

[csswg-drafts] [web-animations-1] Should async playback methods return the `ready` Promise?

From: Brian Birtles via GitHub <sysbot+gh@w3.org>
Date: Fri, 19 Jan 2018 08:23:45 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-289895971-1516350224-sysbot+gh@w3.org>
birtles has just created a new issue for https://github.com/w3c/csswg-drafts:

== [web-animations-1] Should async playback methods return the `ready` Promise? ==
It's common when using the API to write:

```js
anim.play();
anim.ready.then(() => {
   // do stuff
});
```

or,

```js
anim.play();
await anim.ready;
// do stuff
```

This would be much simpler if `anim.play()` simply returned the `ready` Promise so you could write:

```js
anim.play().then(() => {
   // do stuff
});
```

or,

```js
await anim.play();
// Do stuff
```

Likewise, of course, for `pause()`, `reverse()`, `updatePlaybackRate()`.

We've discussed this in the past and the trouble has always been that we were concerned that people would assume that the Promise returned was the `finished` Promise and erroneously write:

```js
anim.play().then(() => {
   // Animation is finished now, do cleanup.
});
```

My hunch is that the convenience of being able to wait on the result of `play()`, `pause()`, `reverse()`, and `updatePlaybackRate()` outweighs the risk that a few people will get it wrong but I'm not sure. I'm used to async methods being fine-grained but that might just be the APIs I tend to use. Perhaps a significant number of people would expect waiting on `anim.play()` to resolve when the animation was finished, I'm not sure.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2206 using your GitHub account
Received on Friday, 19 January 2018 08:23:47 UTC

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