W3C home > Mailing lists > Public > public-media-fragment@w3.org > May 2011

Re: Temporal media fragment for HTML media questions

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 10 May 2011 21:48:07 +1000
Message-ID: <BANLkTi=Hpe_Hk28+ts5pUQ4EJSduq_GLng@mail.gmail.com>
To: Chris Double <cdouble@mozilla.com>
Cc: Media Fragment <public-media-fragment@w3.org>
On Tue, May 10, 2011 at 9:21 PM, Chris Double <cdouble@mozilla.com> wrote:
> On Tue, May 10, 2011 at 9:24 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>> How would you change the spec to say what you were intending to implement?
>> There's no mechanism for suppressing the seeking events currently, for
>> example.
>
> Yes, you raise good points. I think it might be better for me to
> change to the way the HTML spec specifies it (I wasn't aware that had
> changed to support media fragments - thanks for pointing it out).
>
>> Good point. As another issue, it would be ideal if it behaved exactly as if
>> one had used a cue range with the pauseOnExit flag, so that this logic can
>> be shared in implementations and so that it's possible to emulate MF using
>> cue ranges in browsers that only implement the latter.
>
> Yes, that makes sense.
>
>> I'm quite skeptical of making the behavior stateful like this. If the user
>> tries to seek to the beginning of the fragment but ends up right before it
>> due to rounding errors, don't you think it would be annoying and confusing
>> if the fragment stopped "working" from then on? IMO it would be better to
>> always have the fragment present and always pause when reaching the end
>> time.
>
> I'm happy to do it the way you suggest. I haven't been a huge user of
> media fragments (using existing implementations like YouTube's URL
> format) so I have no problem changing what I've done to fit ways
> people want to use it.

Do experiment with it to make yourself an opinion of what would be
best UI wise - I am not convinced either way. :-)

Cheers,
Silvia.
Received on Tuesday, 10 May 2011 11:49:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:46 UTC