Discussion on bugs to send to HTML5 WG

Hi all,

In today's phone conference we briefly discussed the HTML5  [Bug
10723] support for media fragment URIs in relevant HTML5 elements .

I had proposed to start the following new bugs as a consequence of
rejecting Bug 10723:

==
1. Interpretation of temporal media fragment URI in browser navigation:

Problem: what is a browser expected to do when a user navigates to a
media resource with a media fragment

Proposal: similarly to how
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid
explains how a browser has to scroll to a document offset on seeing a
HTML fragment, we also need to explain browser behaviour for media
fragment URIs. The expectation by the Media Fragment WG is that a
browser will start playback at the given start time offset and stop it
at the given end time offset.


2. User interface of temporal media fragment URI in browser navigation:

Problem: what is a browser expected to display when a user navigates
to a media resource with a media fragment

Proposal: Since the browser will display default controls, we need to
introduce markers on the controls for the fragment, see
http://www.youtube.com/watch?v=LfRRYp6mnu0 for an example implementation.


(We could also ask for 2 more bugs on changing the url on "pause" and
adding it to the browser history, but I think that's something for a
later time and not so important.)


3. User interface of temporal media fragment URI in @src of video element:

Problem: what is a browser expected to display in @controls when a
<video> or <audio> element loads a media resource with a media
fragment

Proposal: The browser will play the resource from the start time to
the end time and pauses at the end time. It further displays the time
segment on the timeline of the @controls in a suitable manner as part
of the full video's timeline. If the user hits "play" at the end of
the fragment playback, playback will continue past the end of the
playback until it reaches the end of the resource or another user
interaction occurs.


4. Effect when @src of video element contains temporal media fragment
URI and @loop:

Problem: what is a browser expected to loop over when a temporal media
fragment URI is given in a @src attribute of a media resource

Proposal: The browser will loop over the fragment unless there is user
interaction. The fragment constraint will be lifted as soon as the
user changes the playback position in any manner.


5. User interface of spatial media fragment URI in <img> or <video>
resource, or in browser navigation:

Problem: what is a browser to display when the browser navigates to a
image or video resource with a spatial media fragment URI, or when the
@src attribute of a <img> or <video> element contains a spatial media
fragment URI

Proposal: a cropped (spliced) image or video is displayed to the user
by hiding the other pixels from the user.


6. User interface of track media fragment URI in <audio> or <video>
resource, or in browser navigation:

Problem: what is a browser to play back when the browser navigates to
a audio or video resource with a track media fragment URI, or when the
@src attribute of a <video> or <audio> element contains a track media
fragment URI

Proposal: The browser will only play back/decode the tracks that are
enumerated in the track media fragment URI. An example use case has
been shown at https://labs.ericsson.com/developer-community/blog/beyond-html5-conversational-voice-and-video-implemented-webkit-gtk.

==

At the phone conference I was told that we had resolved that we only
need to follow up on the end time and on what to do with @loop.

However, I think we need to make the statements above and some of them
will have consequence onto the spec.

If people disagree, can you please state why so we can move on?

Thanks,
Silvia.

Received on Wednesday, 2 February 2011 10:49:45 UTC