Hi,
Thanks for looking into this!
On 2015/04/24 7:13, Shane Stephens wrote:
...
> This is a really good summary of the different states and how to
> transition between them. Could we insert this in the non-normative text
> of the spec?
Thanks. I filed issue #92 for this.[1]
> I thought about this for a while and had some ideas for introducing a
> more primitive run()/resume()/start() operation. Apart from
complicating
> the API I've come to think that play() isn't that bad. We seek to
one of
> the interval endpoints when transitioning from the 'idle' state so it
> doesn't seem so bad to do exactly the same thing when
transitioning from
> the 'finished' state.
>
>
> One difference between transitioning from idle and transitioning from
> finished is that we don't have a currentTime in idle, so we *need* to
> construct one. So these aren't really the same thing.
Yes, they're different. I think they're similar? Do you have any
suggestion for a more primitive operation?
> b. Some people want the async methods play()/pause() to return
Promise
> objects.
...
> Good summary. I think there's still enough uncertainty around this to
> punt on promises as return values in level 1. It's something we can
> easily introduce later, but changing once introduced will be much harder.
Agreed.
> c. The ready promise is reused. If you do pause() and then
interrupt it
> with play() we don't create two separate Promise objects, but
just reuse
> the one created when you called pause(). The idea is that the ready
> promise doesn't resolve until eveything is ready. I'm not sure if
this
> is useful or not. If pause() and play() were to return Promise
objects
> it would probably make more sense that they are separate
'pause-ready'
> and 'play-ready' promises which get cancelled if the operation is
> aborted.
>
>
> This is probably worth thinking about from a use-case perspective. Are
> there situations we can think of where it's important to know that the
> pause() was cancelled?
Yeah, I'm really not sure. It's possible that the two approaches are
compatible. Namely, that you could have pause() and play() return
specific 'pause-pending' and 'play-pending' promises but have the
'ready' attribute continue to behave as currently specced--i.e. a
combined promise.
> d. On a related note, should we expose 'play-pending' and
> 'pause-pending' as separate states? Currently they're both just
reported
> as 'pending'.
I'd be keen to hear thoughts on this.
> f. It's odd that if you're paused and call finish(), you don't
end up in
> the 'finished' state. If 'finished' is a subset of 'running', then I
> think it makes sense for finish() to take you out of the paused
state.
> It could do this by simply resolving the start time appropriately.
>
>
> It does from the perspective of the states, but also it doesn't make
> sense intuitively for finish() to unpause you.
I think the basic issue is that 'finished' and 'paused' overlap and
states shouldn't do that. I suggest we fix this by making 'finished' and
'paused' never overlap--i.e. if you're paused, you're not finished. In
my follow-up mail[2], I added point (h) which suggests that we don't
resolve the finished promise so long as you're paused.
If 'finished' and 'paused' don't overlap then I think having finish()
transition you out of the paused state makes more sense but that's
probably a secondary issue. We should work out how finished and paused
fit together first.
> Maybe we don't need finish()? It's trivial to implement yourself
> (player.currentTime = player.endTime).
Perhaps. I'd somewhat like to keep it since I find it useful and jQuery
programmers are used to it. It's also slightly complicated to do it
yourself:
player.currentTime = player.playbackRate > 0 && player.effect
? player.effect.computedTiming.endTime
: 0
*Plus* special handling when player.effect.computedTiming.endTime ==
Infinity or player.playbackRate == 0.
> g. Should calling pause() while idle transition to the 'paused'
state?
> i.e. resolve the current time to the appropriate end of the
interval? To
> create an initially paused animation you currently need to call
play()
> then pause() (or just set the currentTime). Amongst the three
primitive
> operations introduced above there's no operation that triggers an
> idle->pause transition.
>
>
> That sounds like a good idea.
Great. I'll wait until we settle on the other issues before making that
change.
Thanks,
Brian
[1] https://github.com/w3c/web-animations/issues/92
[2] https://lists.w3.org/Archives/Public/public-fx/2015AprJun/0024.html
