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, 4 Mar 2010 16:52:31 +1100
Message-ID: <2c0e02831003032152q518be022nf0322c062528facd@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Eric Carlson <eric.carlson@apple.com>, "Michael(tm) Smith" <mike@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Thu, Mar 4, 2010 at 4:08 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Thu, 04 Mar 2010 11:45:43 +0800, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>> On Thu, Mar 4, 2010 at 2:27 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>
>>> On Mar 3, 2010, at 12:40 PM, Silvia Pfeiffer wrote:
>>>
>>>> On Thu, Mar 4, 2010 at 3:33 AM, Eric Carlson <eric.carlson@apple.com>
>>>> wrote:
>>>>>
>>>>> On Mar 2, 2010, at 11:14 PM, Silvia Pfeiffer wrote:
>>>>>
>>>>>>>
>>>>>>> You also didn't answer my second question -  are track names
>>>>>>> typically
>>>>>>> unique? Do media container formats generally guarantee the presence
>>>>>>> of
>>>>>>> unique track names?
>>>>>>
>>>>>> There is no guarantee of their existence - same for the role
>>>>>> attribute. But where they exist, they are unique.
>>>>>>
>>>>>  Track IDs (which are numeric) in QuickTime and MPEG-4 files are
>>>>> guaranteed to be unique, track names are not required and are *not*
>>>>> guaranteed to be unique.
>>>>
>>>>
>>>> So maybe for MPEG the track ID is the one that should be mapped to the
>>>> this field here as text? Or alternatively it could be a combination of
>>>> track name and the track ID?
>>>
>>> It seems like you can always provide a numeric indexing API to the tracks
>>> regardless of the media format. How about we make that the primary way to
>>> query for a track, and leave the name as an informative field?
>>>
>>> Using a numeric ID as a string name would be particularly confusing with
>>> the
>>> proposed API, since there are both name and index getters. Let's say you
>>> have a track that is first in the MediaTracks list, and it has a numeric
>>> track ID of "2".
>>>
>>> You might expect that myVideoElement.tracks["2"] will get the track with
>>> ID
>>> 2. But it will instead get the third track in the tracks list. That's
>>> because index getters take priority over name getters, and
>>>  myVideoElement.tracks[2] means the same thing as
>>>  myVideoElement.tracks["2"] in JavaScript. For this reason, it is a bad
>>> idea
>>> to provide both index getters and name getters when the names may be
>>> numeric.
>>>
>>> I suggest that we drop the name getter, since the index getter is more
>>> fundamental. No matter what kind of query you want to do, you can alway
>>> loop
>>> over all the tracks using tracks.length and the tracks index getter.
>>
>> OK, I see the problem. I didn't consider that JavaScript converts sees
>> no difference in [2] and ["2"].
>>
>> I have no issue with removing the getter on namedItem. I don't think
>> it's important.
>> The other getter already does the index by number.
>
> I agree with removing it. The only reason it was there to begin with was
> because the HTMLCollection interface was copied. The remaining
> tracks.item(n) is not very useful as it is only a longer way of writing
> tracks[n]. Is it really necessary to keep it for these hypothetical
> non-ECMAScript languages that might implement the interface?


I would keep it as such, since it is consistent with other such interfaces.

Cheers,
Silvia.
Received on Thursday, 4 March 2010 05:53:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:03 GMT