- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 3 Mar 2010 18:07:14 +1100
- To: "Michael(tm) Smith" <mike@w3.org>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Ups, sorry - that was Maciej's reply and not yours and he has already removed it. Anyway - those were good questions and worthy of a reply. Cheers, Silvia. On Wed, Mar 3, 2010 at 6:03 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > Hi Michael, > > I saw your questions on the proposal, so thought I should reply immediately. > >> 1) Is it a common use case to want to get a track by name? Is it common for tracks in a media file to even have unique names? >> I am not sure namedItem() is justified. > > A name is the best possible way to address individual tracks. That > name may well be a number in some media file formats, but the most > general case is to provide a string. > > >> 2) Isn't it more likely that you'd want to get all the tracks of a given role? I think getTracksByRole() might be a more useful >> API addition. > > It may indeed turn out that this most basic API needs some extensions. > For now, we just want to be able to expose the most important > information about the tracks of a media resource to the browser. > getTracksByRole() can be simulated with this given API, so it is > strictly not necessary. It would however be a valuable simplification > for JavaScript. I'd suggest we get the basic implementation first > before we ask browser vendors to make more complicated convenience > functions. > > >> 3) This API offers a very general ability to introspect the available tracks. It seems more power than is strictly needed just for >> captioning purposes. Do we have use cases for the more general uses for this API? > > We are indeed looking at far more than captions here, which is why > this is not called a caption API, but a multitrack media API. It > allows also access to tracks such as sign language video tracks or > audio description audio tracks or in fact other audio, video or text > tracks that may be available inside a multitrack media resource. A > simplification of this API by specialising it only for captions would > not make sense since firstly the API could not be made much simpler > and secondly we need the full access to all available tracks anyway, > so should solve the problem properly. > > > Best Regards, > Silvia. > > > On Wed, Mar 3, 2010 at 5:35 PM, Michael(tm) Smith <mike@w3.org> wrote: >> A survey is ready on the "Media Multitrack API" draft change >> proposal. >> >> http://www.w3.org/2002/09/wbs/44061/multitrack-api/ >> >> The survey asks you to evaluate the proposal, which is for a >> JavaScript API for extracting basic information about tracks >> contained inside a media (audio or video) resource, and indicate >> whether you support submitting it to the HTML WG as a decision >> from the a11y TF; it also provides you with an opportunity to >> suggest changes to the proposal, and, if you indicate that you >> don't support submitting the proposal to the group, asks that you >> provide a comment giving your reasons. >> >> Only members of the HTML Accessibility Task Force can complete >> this survey. It is only a straw poll of the members of this task >> force. However, note that the results are publicly visible: >> >> http://www.w3.org/2002/09/wbs/44061/multitrack-api/results >> >> -- >> Michael(tm) Smith >> http://people.w3.org/mike >> >> >> >> >
Received on Wednesday, 3 March 2010 07:08:08 UTC