Re: [web-animations] API sketch for updated Player behaviour

Hi Shane,

Thank you very much for helping nut out this part of the API.

(2013/10/17 18:37), Shane Stephens wrote:
>     * ended - this is taken from HTMLMediaElement. It gets set whenever
>     currentTime >= source.endTime (unless I guess playbackRate < 0 and
>     currentTime == source.endTime?) This is asymmetrical--it doesn't get
>     set when you finish playing in reverse, but that's also how it works
>     in HTMLMediaElement.
>
>
> It's a shame this is asymmetric. How important is it to match
> HTMLMediaElement's behaviour? I don't think that reverse play is as much
> of a consideration for media as it is for animations (but I could be wrong).
>
> If we have to match HTMLMediaElement, maybe we could add another
> attribute that is antisymmetric to ended?

We probably need some flag to differentiate between a player that is 
playing its first frame and one that is waiting to start or has finished 
playing backwards since both will have currentTime = 0.

So we could have:

* A 'started'/'ended' pair and keep some sort of similarity with HTML
* A single value indicating if we're in this out-of-interval semi-paused 
state, e.g. 'playing'

Related to this is events for players. If we were to define events for 
players would they be 'start' and 'end' and would they be switched in 
reverse? The current event text for timed items (which will very likely 
be rewritten) uses 'end' to mean 'stopping playing' from either direction.

In light of that, maybe 'playing' is better since if we define an 'end' 
event for players we'd probably fire it when you finish playing 
backwards too---and that would not be consistent with the 'ended' attribute.

So I guess I lean towards replacing 'ended' with a 'playing' value.

>     * cancel() - sets source to null. Causes all animation effects
>     produced by this player to be cleared.
>
>
> Does this also reset timeLag? What about currentTime and startTime?

Good question. My guess is no, it's doesn't touch any of those items. If 
you want a player with no source content and no time lag, you should 
make a new player (document.timeline.play(null)).

>     * finish() - jQuery has this and I've sometimes wanted it. Not sure
>     what it should do when playbackRate < 0 but for the forwards case,
>     it seeks to source.endTime.
>
>
> (a) I'd like it to seek to the edge of the playback range in the current
> direction, so that when playing in reverse finish() would seek to the
> start. This means that:
> finish();
> reverse();
> will always do full playback of the content in the opposite direction to
> last time.

Sounds good.

> (b) Does finish() seek backwards to source.endTime if the play head is
> past endTime already?

Good question. I suspect "yes" is the more useful behaviour.

>     * play() - unpauses if paused is true. In HTML, if you're ended it
>     seeks back to the start. I think we should probably do that here for
>     consistency even though I don't like these operations that produce
>     very different behaviour whether you call them 1ms before or after
>     the player finishes.
>        Not sure what we should do if:
>          - currentTime > source.endTime and playbackRate < 0 -- suggest
>     we seek to source.endTime
>          - currentTime < 0 and playbackRate < 0 -- do nothing? or seek
>     to source.endTime?
>          - currentTime < 0 and playbackRate > 0 -- suggest we seek to 0
>          - playbackRate = 0 -- do nothing I guess
>        HTML only does restart behaviour when playback is forwards but we
>     might want to deviate from that depending on how we define reverse.
>
>
> I agree that seeking back to the start is inelegant, but that it seems
> like it's worth matching HTML's behaviour here. I think your suggestions
> for edge cases are good - I'd seek to source.endTime in the second case
> to remain symmetric.

Sounds good.

Thanks again,

Brian

Received on Friday, 18 October 2013 02:23:49 UTC