W3C home > Mailing lists > Public > public-media-fragment@w3.org > September 2010

Re: minutes of 2010-09-08 teleconference

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 14 Sep 2010 23:14:10 +1000
Message-ID: <AANLkTikPKUbTOcApxU1xoV39GFzXd+zfKxFyChP38F=q@mail.gmail.com>
To: Jack Jansen <Jack.Jansen@cwi.nl>
Cc: RaphaŽl Troncy <raphael.troncy@eurecom.fr>, Erik Mannens <erik.mannens@ugent.be>, public-media-fragment@w3.org
On Sun, Sep 12, 2010 at 6:42 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:

>
> On 10 sep 2010, at 13:01, Silvia Pfeiffer wrote:
>
> > It may actually be a good thing to propose spec text for the HTML spec,
> because it will then make it a necessity for the browser vendors to
> implement support and they understand what is actually asked of them.
>
> My angle would be the following (but note that I'm now pretending I'm an
> HTML/scripting guy).
> There are two things HTML could do with media fragments: (a) display
> something reasonable, (b) pass the fragment parameter on to the DOM, so a
> script can do something more elaborate.



(b) isn't what HTML does with fragments of URIs.



> (a) is the most sensible default. Whatever they display is actually not all
> that important, as webpage/app designers should be able to override it.
>
> So I would suggest that they make the parameters of the MF url available to
> scripting, as attributes on the HTMLMediaElement interface. This enables
> scripts to access the MF data without duplicating the URL-parser.
>

We can already retrieve the URL for JavaScript - no new features are
necessary.
You can get the url of the video element as video.currentSrc which gives you
the url and you can easily parse out the fragment. I have done just that in
the demo at http://www.annodex.net/~silvia/itext/mediafrag.html . You could
put a convenience function into HTML5 for the media elements to have e.g.
video.fragment or something do it for you. I am assuming that's what you
meant by adding it to the HTMLMediaElement - just adding an IDL attribute.
I'm not sure that's necessary because nothing else in HTML5 has convenience
functions for URL parsing.



> By default, the browser would render only the MF-addressed part of the
> media. For convenience, they should render a time-based MF in context (i.e.
> putting in- and out-point at the beginning and end specified by the MF) and
> spatial MF out-of-context (i.e. cropping to the requested rectangle).


I think I agree with this.



> However, scripts or webpages need a way to override this behavior.


I don't think that makes much sense, because then it's not standardised any
more.



> One possibility is to specify (a) when the HTMLMediaElement attributes are
> filled in and (b) when they are interpreted by the renderer, with the script
> having a chance to fiddle the MF parameters in between.


That's not going to happen - the process to load the media resource is
already hugely complex and there are dependencies in there that cannot be
interrupted by handing over control to a authored script. Would also be a
huge security risk actually.



> Something like "loadstart" event seems like an option: if the browser first
> parses the URL and MF and puts the info in the DOM attributes, then raises
> "loadstart", then uses the parameters from the attributes this sequence
> gives a script a chance to override the default treatment of the MF.
>


> But another option would be to add an HTML-attribute (like
> interpretMediaFragment="false") or CSS styling attribute to forestall the
> default behavior.
>

Putting an attribute on the media elements or introduced a CSS style to
determine how the resource is rendered may be possible, I don't know. I am
not sure I would want to fight for this in HTML5. I think that all the
highlighting can easily be done with HTML5 functionalities (SVG or Canvas on
a video element to provide the highlighting or the annotation), so I would
think that doing it all in script and not through the URL seems preferrable.

Cheers,
Silvia.
Received on Tuesday, 14 September 2010 13:15:04 GMT

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