Re: [web-animations] Rationalizing the Animation interface

On 2015/04/14 16:39, Brian Birtles wrote:
...
> e. Should 'paused' really win over 'finished'? The fundamental problem
> here is that 'paused' and 'finished' are really orthogonal. It's
> possible to be both at once. That said, I'm less than enthusiastic about
> splitting this out in the API since I think it overcomplicates it (e.g.
> if you wanted to check if the animation is actually moving you'd have to
> check anim.playState == 'running' && !anim.isFinished).
>
> In regular circumstances you won't end up in the paused-and-finished
> state since you won't hit the end of the animation until you resume the
> animation. It's only when you're doing manual seeking or adjusting the
> duration of in-play animations that this situation arises.
>
> If we accept the three fundamental states I proposed at the start of
> this email and treat 'finished' as a subset of 'running' then I think it
> makes sense for an animation with no start time and a current time
> outside the animation's range to be 'paused' (i.e. no change).
>
> 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.
>
> g. ...

h. One further thought, if 'finished' is to be a strict subset of 
'running' then we probably shouldn't resolve the finished promise or 
dispatch finished (or animationend etc.) events while we're still in the 
'paused' state. That is, if you pause then seek past the end of the 
effect, you are still in the 'paused' state and don't resolve the 
finished promise (since that would suggest you had entered the finished 
state).

Received on Monday, 20 April 2015 05:04:19 UTC