Re: [web-animations] Making players stop

Hi Brian and list,

I like option C best out of A-C, because I think it fits well with
intuition and has nice properties with regards to reversal and play-on of
appended animations.

I don't think that the statefullness of this option is a drawback - to me
it feels like Groups are the unit of synchronization, not Players. For
example, to implement the use case you discussed, I'd recommend that you
put the async resource in a Par Group along with the sync resource. This
will ensure that the resources are permanently in lock-step.

I'm afraid I don't really understand option D. Would you mind explaining it
in more detail?

Thanks,
    -Shane Stephens


On Thu, Oct 17, 2013 at 5:54 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> 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<http://lists.w3.org/Archives/Public/public-fx/2013OctDec/0059.html>
>
>