[Bug 10723] support for media fragment URIs in relevant HTML5 elements

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723

--- Comment #8 from Philip Jägenstedt <philipj@opera.com> 2010-12-15 13:16:40 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > 
> > > 1. URL in address bar
> > > 
> > > The means towards interpreting the fragment should be by starting to download
> > > the resource, then, as it is confirmed that it is a media resource, download
> > > will stop and byte range requests will be applied.
> > 
> > This kind of advice, if it should be given, should be in the MF spec.
> > 
> > > Note further that for any video or audio that is playing in this way, it makes
> > > sense to update the URL bar when pausing and to include the fragment offset,
> > > such that users can cut and paste the new URL for sharing.
> > 
> > We could make the context menu for <video> do this, but I don't think we want
> > the address bar to double as a playback progress indicator.
> 
> 
> It's not about playback progress. It's about fragment progress. People pause a
> video for a reason - the pause sets a marker to get back to later, or a marker
> to identify interesting bits to share with others, or a point where the viewer
> lost interest (and may want to get back to later). The intent with updating the
> URL is to provide what is natural in browser history to users, namely a
> location to get back to. You can try it for yourself at
> http://www.annodex.net/~silvia/a11y_bcp/demo1_navigation.html (even though that
> is an example of a web page rather than a video resource).

Ah, I missed the (critical) part about pausing. Agreed, this would be better
than continuously updating the URL.

> > > Also, it might make
> > > sense to add the new URL to the browser history when pausing, allowing the user
> > > to jump back and forth between pause points through navigating the browser
> > > history.
> > 
> > Opera already does this, but it doesn't involve changing the URLs in history.
> > Rather, all the state is saved and restored when coming back, including the
> > last frame, volume and muted state. It's still a bit flaky, but mostly works.
> 
> All the state, including the playback position and fragment? That sounds nice!

Yes, we try to make it so that a script that was running before the page was
suspended and put into history won't notice that anything has happened when the
page/script/video resumes. There are known bugs, but that's the idea.

> > > Note that if the @loop attribute is given, the fragment will loop and not the
> > > resource.
> > 
> > What should happen if the loop attribute is present, but the user seeks outside
> > the given fragment? Where should it seek when reaching the end of the resource?
> 
> 
> I think there would be an inherent "am in fragment" state. Once the user breaks
> out of the fragment through whatever means, none of the fragment context is
> valid any longer, which includes loop boundaries. It goes back to the full
> video.

Works for me.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 15 December 2010 13:16:43 UTC