Re: Discussion on bugs to send to HTML5 WG

Hi Silvia, all,

As outlined on the call, I think a clarification would be good in
order to assure that we're exclusively speaking about hash Media
Fragment URIs (#t, #xywh, etc.) in these bugs, but not about
resource-creating query Media Fragment URIs (?t, ?xywh, ?track, etc.).

Further comments inline:

> 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.
+1 for the bug. Do these cases (see the URIs below) need clarification
(or specific mention)?

Web pages with embedded video content (Out of spec. Still a good idea?
Allows users to set "video anchors" on a page similar to YouTube
[http://www.mattcutts.com/blog/link-to-youtube-minute-second/].):
1) example.com/index.html#t=1,10 and index.html contains just 1 <video
src="x.webm"> element
2) example.com/index.html#t=1,10 and index.html contains more than 1
<video src="x_1.webm"> ... <video src="x_n.webm"> elements
Direct link to video resources (you point the browser to the video,
not an HTML page containing it):
3) example.com/x.webm#t=1,10
Indirect link to video resources (you point the browser to an HTML
page containing one or several videos):
4) <video src="x.webm#t=1,10">

Basically my question is: shall we explain all these cases in the bug,
or explicitly state what we're focusing at?

> 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.
+1 for the bug.

> (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.)
Same questions apply as above.

> 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.
+1 for the bug.

> 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.
+1 for the bug.

> 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.
We should probably clarify then that this (xywh) is to be exclusively
used for cropping content, not to somehow highlighting parts of the
content. We should also probably mention that highlighting content can
be achieved with CSS. This, at least for images (not sure about
video), is also true for cropping. We need strong arguments in order
to make sure why CSS is not good enough.

> 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.
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-track
allows subtitles as a track dimension. Do we need to clarify what this
means? How should a browser deal with this? We need to clarify the
expected behavior in my opinion (or restrict "track" to moving visual
or hearable, but not textual content).

What do you think?

Best,
Tom

-- 
Thomas Steiner, Research Scientist, Google Inc.
http://blog.tomayac.com, http://twitter.com/tomayac

Received on Wednesday, 2 February 2011 12:31:31 UTC