- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 12 Feb 2015 13:11:19 +1100
- To: Aleksei Semenov <a.semenov@unipro.ru>, public-fx@w3.org
- CC: "dom@unipro.ru" <dom@unipro.ru>
On 2015/02/10 18:03, Aleksei Semenov wrote: > The procedure to pause a player reads ( > http://w3c.github.io/web-animations/#pause-a-player ): >> ... >> 6. Schedule a task to be executed at the first possible momentafter >> the user agent has performed any processing necessaryto suspend the >> playback of player’s source content, if any.The task shall perform the >> following steps: >> ... > > I think, that meaning "Schedule a task" also allows to execute the task > immediately. We need to tighten up that wording. The intention is that it should not run synchronously. >> As a result, the subsequent call to player.play() will happen *before* >> the callback is run. > > Unfortunately, I am not so good with the Promises spec. > But isn't possible for promise to execute the function immediately, > instead of scheduling a microtask? No, it's not possible. >>> Is it possible to change the specification, that each method >>> (play, pause, reverse, finish) return unique Promise object related >>> to the method. So the following promise-like code could be possible: >>> >>> player.pause().then(handlePause, rejected); >>> player.play().then(handlePlay, rejected); >>> player.finish().then(handleFinish, rejected); >> >> I prefer this but the main problem is just the naming of play(). What >> do you think of using resume()? > > resume() is a counterpart of pause(). > But resume() does not look well for beginning of the playback. > I think start() as a counterpart to finish() would be better. > And I like the idea that play().then( ... ) would execute after the > animation had finished. Yes, that seems like a sensible proposal. I'll talk it over with Shane later today. Thanks again, Brian
Received on Thursday, 12 February 2015 02:11:53 UTC