At 14:20 +1000 23/05/08, Silvia Pfeiffer wrote:
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 think the two have different purposes and use-cases, don't they?
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?
As I see it (and others may have other ideas),
* with fragments in the URL, I can identify sub-sets of a resource
that I would like to present or select;
* with timeranges in the markup, I can get notified when 'interesting
parts' of the resource are being presented.
An example use-case for timeranges is if you want to flip an HTML
explanatory frame alongside a video. As the subject of the video
changes, or the scene, you want to put different explanatory material
in the adjacent frame. Timeranges make that easy; if you have N
pages of explanation, which each apply to a sub-section of the video,
make N timeranges and have the enter event of each flip in the
appropriate explanation. Note that this works even with seeking, the
way it's defined.
There are, of course, other use cases.
Does this help?
Best Regards,
Silvia.
On Fri, May 23, 2008 at 4:53 AM, Dave Singer <[EMAIL PROTECTED]> 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
--
David Singer
Apple/QuickTime
