- From: Sean Hayes <Sean.Hayes@microsoft.com>
- Date: Mon, 18 Apr 2011 15:32:21 +0000
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, "Ian Hickson (ian@hixie.ch)" <ian@hixie.ch>
- CC: Paul Cotton <Paul.Cotton@microsoft.com>, "Sam Ruby (rubys@intertwingly.net)" <rubys@intertwingly.net>, "Maciej Stachowiak (mjs@apple.com)" <mjs@apple.com>
If the clarifications I proposed last week are included (i.e. to indicate expressly that the <video> element operates on audio only data, and has a display rectangle to renders captions into, even if there is no video data supplied), then I would formally withdraw my CP in favor of Proposal 4 as amended. -----Original Message----- From: public-html-a11y-request@w3.org [mailto:public-html-a11y-request@w3.org] On Behalf Of Silvia Pfeiffer Sent: 18 April 2011 12:49 To: HTML Accessibility Task Force Subject: Re: [media] progress on multitrack api - issue-152 Note that I have certainly missed issues, so do speak up if you've noticed anything. Cheers, Silvia. On Mon, Apr 18, 2011 at 12:05 AM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > Hi all, > > In the last media subgroup meeting we further discussed the different > change proposals that we have for issue-152. > > A summary of all the submitted change proposals is at > http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposals_Summary > . > > We discussed that Proposal 4 can, with a few changes, provide for the > requirements of in-band and externally composed multitrack resources. > Proposal 4 introduces an interface for in-band audio and video tracks, > and a Controller object to maintain the shared state between the > individual media elements that together make up a composed multitrack > resource. > > This email serves two purposes: > > Firstly it asks others on the accessibility task force whether there > are any objections to going with proposal 4 (Philip?, Geoff?). The > people present at the meeting agreed that they would be prepared to > withdraw their change proposals in favor of proposal 4. This include > all proposals numbered 1 to 3 on the summary page. > > Secondly it summarizes the remaining issues that we would like > addressed for proposal 4. > > The remaining issues are: > > (1) videoTracks should be MultipleTrackList, too: > > The current HTMLMediaElement has the following IDL to expose in-band > media tracks: > readonly attribute MultipleTrackList audioTracks; > readonly attribute ExclusiveTrackList videoTracks; > > The objection is to the use of ExclusiveTrackList on videoTracks. It > should be allowed to have multiple in-band video tracks activated at > the same time. In particular it seems that MP4 files have a means of > specifying how multiple video tracks should be displayed on screen and > Safari is already able to display such. > > In contrast, proposal 4 requires that only one in-band video track can > be active and displayed into the video viewport at one time. If more > than one video track is to be displayed, it needs to be specified with > a media fragment URI in a separate video element and connected through > a controller. > > Some questions here are: what do other browsers want to do with > multiple in-band video tracks? Does it make sense to restrict the > display to a single video track? Or should it be left to the browser > what to do - in which case a MultipleTrackList approach to videoTracks > would be sensible? If MultipleTrackList is sensible for audio and > video, maybe it could further be harmonized with TextTrack. > > > (2) interface on TrackList: > > The current interface of TrackList is: > readonly attribute unsigned long length; > DOMString getName(in unsigned long index); > DOMString getLanguage(in unsigned long index); > attribute Function onchange; > > The proposal is that in addition to exposing name and language > attributes - in analogy to TextTrack it should also expose a label and > a kind. > > The label is necessary to include the track into menus for track > activation/deactivation. > The kind is necessary to classify the track correctly in menus, e.g. > as sign language, audio description, or even a transparent caption > track. > > > (3) looping should be possible on combined multitrack: > > In proposal 4 the loop attribute on individual media elements is > disabled on multitrack created through a controller, because it is not > clear what looping means for the individual element. > > However, looping on a multitrack resource with in-band tracks is well > defined and goes over the complete resource. > > In analogy, it makes sense to interpret loop on a combined multitrack > resource in the same way. Thus, the controller should also have a > muted attribute which is activated when a single loop attribute on a > slave media element is activated and the effect should be to loop over > the combined resource, i.e. when the duration of the controller is > reached, all slave media elements' currentTime-s are reset to > initialPlaybackPosition. > > > (4) autoplay should be possible on combined multitrack: > > Similar to looping, autoplay could also be defined on a combined > multitrack resource as the union of all the autoplay settings of all > the slaves: if one of them is on autoplay, the whole combined resource > is. > > > (5) more events should be available for combined multitrack: > > The following events should be available in the controller: > > * onloadedmetadata: is raised when all slave media elements have > reached at minimum a readyState of HAVE_METADATA > > * onloadeddata: is raised when all slave media elements have reached > at minimum a readyState of HAVE_CURRENT_DATA > > * canplaythrough: is raised when all slave media elements have reached > at minimum a readyState of HAVE_FUTURE_DATA > > * onended: is raised when all slave media elements are in ended state > > or said differently: these events are raised when the last slave in a > group reaches that state. > > These are convenience events that will for example help write combined > transport bars. It is easier to attach just a single event handler to > the controller than to attach one to each individual slave and make > sure they all fire. Also, they help to maintain the logic of when a > combined resource is loaded. Since these are very commonly used > events, their introduction makes sense. > > Alternatively or in addition, readyState could be added to the controller. > > > (6) controls on slaves control the combined multitrack: > > Proposal 4 does not provide any information on what happens with media > elements when the @controls attribute is specified. Do the controls > stay in sync with the controls of the other elements? Do they in fact > represent combined state? Do they represent the state of the slave > resource? What happens when the user interacts with them? Is the > information on the interaction - in particular seeking, muting, volume > change, play/pause change, rate change - handed on to the controller > and do the others follow? > > > > Hopefully we can move forward on all of these issues before the 22nd > April deadline for issue-152. > > Best Regards, > Silvia. >
Received on Monday, 18 April 2011 15:37:17 UTC