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).
