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

I think the two have different purposes and use-cases, don't they?

I am talking about this planned activity and a scheme akin to
the one mentioned here or specified here or

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,

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
 <video src="";>
           <area id="area1" begin="0s" end="5s"/>
 >           <area id="area2" begin="5s" end="10s"/>

 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

David Singer

Reply via email to