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

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

--- Comment #7 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2010-12-15 13:04:28 UTC ---
(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).


> > 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!


> > 2. URL in @src attribute of video/audio element
> > 
> > If the @controls attribute is given, there is a need to introduce markers for
> > the fragment, see e.g. http://www.youtube.com/watch?v=LfRRYp6mnu0 for an
> > example
> > implementation.
> 
> Right, the HTML5 spec could mention this in the long enumeration of possible
> control features.


Yeah, sounds good.


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



> > (2) Spatial Media Fragments
> > 
> > As per: http://www.w3.org/TR/media-frags/#naming-space
> > Relevant to: images & video
> > 
> > Recommended approach to support spatial media fragments: CSS-like, i.e. hide
> > unwanted pixels
> > 
> > A spatial media fragment URI can be used in the URL address bar or in the @src
> > attribute of video/img element.
> > 
> > The user will expect a cropped (spliced) image/video display of the resource.
> 
> In other words, a spatial fragment should affect how
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-video-intrinsic-width>
> is interpreted. Still, it's something HTML5 shouldn't define normatively, as
> the interpretation depends on the MIME type, at least in theory.

There are things defined in HTML5 that depend on a image mime type or on a
text/html mime type. If something is relevant to HTML5, it should be there,
even if it only applies to certain types of MIMEs.



> > (3) Track Fragments
> > 
> > As per: http://www.w3.org/TR/media-frags/#naming-track
> > Relevant to: audio & video
> > 
> > Recommended approach to support track fragments: hide unwanted tracks
> > 
> > A track media fragment URI can be used in the URL address bar or in @src
> > attribute of video/img element. One example use case has been shown at
> > https://labs.ericsson.com/developer-community/blog/beyond-html5-conversational-voice-and-video-implemented-webkit-gtk.
> > 
> > The user will expect that only the enumerated tracks (audio, video, etc.) will
> > be displayed.
> 
> I'm not sure there's any spec change needed here, from HTML's point of view the
> resource is just one with fewer tracks. Again, the interpretation depends on
> the MIME type, in theory.

-- 
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:04:31 UTC