Re: [web-animations] Making players stop

Hi again,

I've thought about this[1] some more and another arrangement comes to mind.

Option D: The perpetual record player with annotations

This is identical to the current arrangement where the current time of 
the player keeps increasing indefinitely but the difference is we still 
add "end-like" behaviour.

Specifically, we still:

* have an 'ended' attribute that gets set when current time > content 
end time.
* can define 'end' events as needed
* can define a 'finish' method to jump to content end time

In essence we act like the player ends but we don't try to fix the 
current time when it does.

On the up-side:
+ there is no hidden "actual current time" (unlike option A)
+ there are no issues with the timing of operations causing different 
results (unlike options B & C)
+ swapping the source content of players or "pre-seeking" a player works 
as expected (unlike option B)

- reverse() is no longer a no-op when called twice

I'm not sure what is better here, option C or D. Option D is much 
cleaner to implement and spec and I'd suggest more internally 
consistent. But if authors expect the current time to stop accumulating 
when a player fires its end event then option C may be better.

If anyone has any gut-feelings, author's intuition, etc. I'd be glad to 
hear it.



[1] "This" being the following post for those following this out of 

Received on Thursday, 17 October 2013 06:54:49 UTC