W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2010

Re: Survey ready on Media Multitrack API proposal

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 11 Mar 2010 15:08:35 +1100
Message-ID: <2c0e02831003102008kf7ff1cfjdd808267c84415d8@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: "Michael(tm) Smith" <mike@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Thu, Mar 11, 2010 at 2:50 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Thu, 11 Mar 2010 08:03:33 +0800, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> + add a DOMString attribute @groupID to the MediaTrack to expose the
>> trackgroup
> What should groupID be for <trackgroup><track>?

This is for the JavaScript API, not the <trackgroup><track>
specification. It goes into the MediaTrack element:

interface MediaTrack {
 readonly attribute DOMString groupId;

> Groups, like tracks, don't
> necessarily have a name or id.

Not when there are no groups. When there is a group, in MPEG, there is
an ID (and in Ogg there will be, too). As for the externally linked
markup, you are right and we may need to introduce a mandatory groupID
attribute on the <trackgroup>. OTOH, we could use the @id attribute,
if only we could require its use.

> If we want to go this way, it would be better to not use <trackgroup> at all
> and put a group attribute on <track>. I don't like either solution, but
> would be happy to continue discussing it in the HTML WG.

We don't need to change the markup for <trackgroup><track> only
because the JavaScript API looks like this. But this is certainly an
opportunity to harmonize the two further.

Received on Thursday, 11 March 2010 04:09:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:54 UTC