Re: minutes of 2010-09-08 teleconference

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.