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

Re: Survey ready on Media Multitrack API proposal

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 11 Mar 2010 16:37:41 +0800
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Michael(tm) Smith" <mike@w3.org>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u9d983d0atwj1d@philip-pc.oslo.opera.com>
On Thu, 11 Mar 2010 14:52:21 +0800, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Thu, Mar 11, 2010 at 3:27 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Thu, 11 Mar 2010 12:08:35 +0800, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>> 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.
>> I'm not a fan of this approach, it just adds boilerplate to achieve the
>> basic use cases of multi-language subtitles:
>> <video>
>>  <trackgroup groupid="any-unique-string">
>>    <track ...>
>>    <track ...>
>>  </trackgroup>
>> </video>
>>>> 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.
>> What about replacing MediaTracks with MediaTrackGroup as per my other  
>> email?
>> This way at least we don't have to make up unique IDs where none are  
>> really
>> necessary (this includes MPEG where the group is an int and doesn't  
>> really
>> carry any interesting information).
> I simply think it is over-engineering. I'd prefer not to introduce
> that much complexity for something this simple.
>> Unless we can agree on something I would prefer if we simply don't  
>> solve it
>> and submit it to the HTML WG as is to get more input.
> It may indeed be necessary. I certainly wouldn't want to hold this up
> because of the grouping, since I think grouping is a nice feature, but
> not a main one.

I agree, but think that the "nice feature" is the possibility of having  
parallel text tracks, while having mutually exclusive tracks is absolutely  
fundamental. If we can't handle grouping in a nice way we can discard it  
and require scripts to achieve parallel text tracks. But let's finish this  
in the HTML WG.

Philip Jägenstedt
Core Developer
Opera Software
Received on Thursday, 11 March 2010 08:38:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC