Re: Discussion on bugs to send to HTML5 WG

Hi Thomas, all,

On Wed, Feb 2, 2011 at 11:30 PM, Thomas Steiner <tomac@google.com> wrote:
> 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.).

Yes, you are completely right. Hash-based fragments is all I was referring to.


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

Yes, this is out of spec and we should probably not mention it in a bug.


> 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

This was the case I referred to with this bug.


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

This is bug 3.


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

Explain just a single one.


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

This is all just about when a media resource is entered into the
browser navigation bar - nothing to do with any other position in a
Web page.



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

That's exactly what I meant with the proposal.


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

There is a discussion on the W3C or WHATWG mailing list from CSS
people who want it to be cropping, so I don't think that will be a
problem.


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

If the only retrieved track happens to be subtitles, then just the
timed subtitles will be shown in a default size video viewport, I
would say.


> What do you think?

Thanks a lot for the feedback.

Silvia.

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

Received on Tuesday, 8 February 2011 13:03:35 UTC