Re: [web-animations] Rationalizing the Animation interface

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

Received on Friday, 24 April 2015 01:33:12 UTC