Re: Discussion on bugs to send to HTML5 WG

I agree that it would be useful. If we had in-context spatial
fragments, then having more than one spatial fragment could be useful,
too (remember my Pulp Fiction demo?). But, as Davy says, this is an
old discussion (I probably even wasn't in the WG when you had it).
Maybe in a future extension we could add a dedicated highlight
fragment...

Tom

On Thursday, February 17, 2011, 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
>> >> Media Fragment URI Demo <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 questioI 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
>
>

-- 
Thomas Steiner, Customer Solutions Engineer, Google Inc.
http://blog.tomayac.com, http://twitter.com/tomayac

Received on Thursday, 17 February 2011 08:35:44 UTC