[whatwg] re-thinking "cue ranges"

[Dave Singer]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080522/d9a434b0/attachment-0001.html>