[whatwg] re-thinking "cue ranges"

[Silvia Pfeiffer]

Hi Dave,

If the W3C standardises time ranges through a URI approach, would
there still be a need to have a specification in the DOM or the HTML
code?

I am talking about this planned activity
http://www.w3.org/2008/01/media-fragments-wg.html and a scheme akin to
the one mentioned here
http://www.w3.org/2001/tag/doc/hash-in-url#id2261226 or specified here
http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html or
here http://www.chiariglione.org/mpeg/technologies/mp21-fid/index.htm.htm.

The idea is that if you specify the fragment of the media in the URL
(e.g. in the src attribute of the video tag), there is no need to
handle it anywhere in the HTML code itself.

I am wondering about the use case for the timerange tag that you are
suggesting - could you explain?

Best Regards,
Silvia.



On Fri, May 23, 2008 at 4:53 AM, Dave Singer <singer at apple.com> wrote:
> WARNING:  this email is sent to both the WhatWG and W3C Public HTML list, as
> it is a proposal.  Please be careful about where you reply/follow-up to.
>  The editors may have a preference (and if they do, I hope they express it).
>
> The following discussion is also in the attached proposal, but reproduced
> here for convenience.
>
> * * * * * *
>
> In the current HTML5 draft cue ranges are available using a DOM API.
>
> This way of doing ranges is less than ideal.
>
> First of all, it is hard to use. The ranges must be added by script, can't
> be supplied with the media, and the callbacks are awkward to handle. The
> only way to identify the range a received callback applies to is by creating
> not one but two separate functions for each range: one for enter, one for
> exit. While creating functions on-demand is easy in JavaScript it does fall
> under advanced techniques that most authors will be unfamiliar with. This
> kind of feature is also not available in all languages that might provide
> access to the DOM API.
>
> Secondly this mechanism is not very powerful. You can't do anything else
> with the ranges besides receiving callbacks and removing them. You can't
> modify them. They are not visible to scripts or CSS. You can't link to them.
> You can't link out from them.
> Thirdly, a script is somewhat strange place to define the ranges. A set of
> ranges usually relates closely to some particular piece of media content.
> The same set of ranges rarely makes much sense in the context of some other
> content. It seems that ranges should be defined or supplied along with the
> media content.
>
> Fourth, this kind of callback API is pretty strange creature in the HTML
> specification. The only other callback APIs are things like setTimeout() and
> the new SQL API which don't have associated elements. Events are the
> callback mechanism for everything else.
>
> In SMIL the equivalent concept is the <area> element which is used like
> this:
> <video src="http://www.example.org/CoolStuff">
>           <area id="area1" begin="0s" end="5s"/>
>           <area id="area2" begin="5s" end="10s"/>
> </video>
>
> This kind of approach has several advantages.
> * Ranges are defined as part of the document, in the context of a particular
> media stream.
> * This uses events, a more flexible and more appropriate callback mechanism.
> * The callbacks have a JavaScript object associated with them, namely a DOM
> element, which carries information about the range.
>
> The main disadvantage is the relative difficulty of creating ranges from
> JavaScript since it requires creating elements and giving them attributes.
> Some sort of shortcut interface could be provided, of course, perhaps
> similar to the existing API.
>
> The SMIL definition is perhaps a little broad and also the name is not
> ideal, if the element is primarily used for generating events vs. linking.
>
> We would like to suggest a <timerange> element that can be used as a child
> of the <video> and <audio> elements.
>
> Note that there is an existing concept called timeranges in the HTML5
> specification; a new name needs to be found for one or the other.
>
> The event listeners should probably be added to HTMLElement where other
> listener attributes are. (You should be able to capture events everywhere,
> not just on target.)
> --
> David Singer
> Apple/QuickTime