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)

However:
- 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.

Thanks,

Brian

[1] "This" being the following post for those following this out of 
context: http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0059.html

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