- From: Eric Carlson <eric.carlson@apple.com>
- Date: Wed, 2 Mar 2011 09:13:20 -0800
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: public-html@w3.org
On Mar 1, 2011, at 11:58 PM, Philip Jägenstedt wrote: > On Tue, 01 Mar 2011 23:51:30 +0100, David Singer <singer@apple.com> wrote: > >> Hi Silvia, friends >> >> Eric and I have been discussing this, and we've added an 8th option to the Wiki, for your consideration. >> >> at <http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API> > > This is like option 2 except that <track> is not a void element and can have <source> child elements, right? > Yes, or "a combination of options 2 and 3" as we note in the text. > For all of the options that don't use <audio> and <video> to represent audio and video tracks, do you consider it a problem that properties of HTMLMediaElement are not available? Some of these allow for interesting conflicts such as looping a slave video but not the master video, but I imagine at least videoWidth, videoHeight and volume would be useful to have. > While some properties of HTMLMediaElement could be useful (eg. videoWidth and videoHeight as you note), I think one advantage of this proposal is that the full media element interface is *not* available on <track>. The timeline of a <track> must be slaved to the clock of the parent media element, so I think it will be difficult to define the behavior of the parent when attributes like playbackRate or loop are changed, or methods like load(), play(), or pause() are called on a track. eric
Received on Wednesday, 2 March 2011 17:14:23 UTC