W3C home > Mailing lists > Public > public-media-fragment@w3.org > February 2011

RE: Discussion on bugs to send to HTML5 WG

From: Davy Van Deursen <davy.vandeursen@ugent.be>
Date: Thu, 17 Feb 2011 09:23:07 +0100
To: "'Silvia Pfeiffer'" <silviapfeiffer1@gmail.com>
Cc: "'Media Fragment'" <public-media-fragment@w3.org>, "'Thomas Steiner'" <tomac@google.com>
Message-ID: <005c01cbce7b$e7fc4500$b7f4cf00$@ugent.be>
Hi all,

I basically agree with the proposal below, except for the one regarding spatial fragments (see below).

> -----Original Message-----
> From: public-media-fragment-request@w3.org [mailto:public-media-fragment-request@w3.org] On Behalf Of Silvia Pfeiffer
> Sent: dinsdag 8 februari 2011 14:03
> To: Thomas Steiner
> Cc: Media Fragment
> Subject: 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.h
> >> tml#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.

I know this is an old discussion, but I still don't like the idea of 'spatial fragments in a browser will always be cropped'.
Suppose that I, as a user, want to highlight my spatial regions instead of cropping them. Then there is no way that I could use a
Media Fragment URI for that, since for instance <img src="foo.jpg#xywh=90,90,50,50" /> would always give me a cropped version in a
browser. Wouldn't it be far more flexible if in- vs. out-of-context could be switched on and off by using media fragment specific
CSS properties? 

For example: 
<img src="foo.jpg#xywh=90,90,50,50" style="spatial-fragment: in-context"/> would highlight the region,
<img src="foo.jpg#xywh=90,90,50,50" style="spatial-fragment: out-context"/> would crop the region.

In fact, the same could be applied for temporal fragments. More advanced CSS controls could be defined as well (e.g., to tweak the
highlight style).

Any opinions?

Best regards,

Davy

-- 
Davy Van Deursen

Ghent University - IBBT
Department of Electronics and Information Systems - Multimedia Lab
URL: http://multimedialab.elis.ugent.be/dvdeurse
Received on Thursday, 17 February 2011 08:23:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:42 GMT