Re: Discussion on bugs to send to HTML5 WG

On Thu, Feb 17, 2011 at 7:23 PM, Davy Van Deursen
<davy.vandeursen@ugent.be> wrote:
> 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).


You can do the highlighting in CSS without having to put the fragment
part into the URL. Since the fragment part in the URL is created by a
Web developer and the Web developer also creates the CSS, that's the
obivous solution:

<img style=" src="foo.jpg" background:url(frame.png)"/>

frame.png just needs to be a frame with a transparent inside. You can
also use a SVG for further effects.

To be honest, if the CSS working group says that having slicing is
more important than having highlights, then I believe them.

Cheers,
Silvia.

>
> 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 10:11:10 UTC