- From: Dave Singer <singer@apple.com>
- Date: Fri, 23 May 2008 15:50:36 -0700
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 <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 -- David Singer Apple/QuickTime
Received on Friday, 23 May 2008 15:50:36 UTC