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 13:58:56 +1100
Message-ID: <2c0e02831003031858q5e040db0sefefe2740223ea9f@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: 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 1:16 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Thu, 04 Mar 2010 04:39:01 +0800, Eric Carlson <eric.carlson@apple.com>
> wrote:
>> On Mar 3, 2010, at 12:34 PM, Silvia Pfeiffer wrote:
>>> On Thu, Mar 4, 2010 at 12:26 AM, Philip Jägenstedt <philipj@opera.com>
>>> wrote:
>>>> On Wed, 03 Mar 2010 21:11:32 +0800, Silvia Pfeiffer
>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>> It believe it already is a free-form string, but with some default
>>>>> roles defined - those roles that made sense. We had a discussion about
>>>>> this at the subgroup teleconf, btw, and agreed that it makes sense to
>>>>> pre-define a set of roles so as to make the obvious roles
>>>>> interoperable. Do you disagree with that proposal?
>>>> What I'm saying is that whatever is in the media resource gets exposed
>>>> as is
>>>> in the API, i.e. the UA makes no attempt to map things to any of the
>>>> predefined values. But this only works if all interesting container
>>>> formats
>>>> already have something like role and the identifiers used are the same
>>>> as
>>>> the ones we want in HTML5.
>>> I think just displaying whatever value the container has defeats the
>>> purpose of a standard API. It will result e.g. in several different
>>> means of identifying "caption" - some would have "CC" others "cap"
>>> others "caption" and there are certainly many other ways of specifying
>>> it.
>>> I think the purpose here is to expose to the Web developer a standard
>>> means of identifying what is in the file. This mapping should be done
>>> by the media subsystem that knows both the media file format and the
>>> HTML standard and can provide for the mapping. It should only expose
>>> directly what the file format stores if it doesn't understand the
>>> name. Otherwise the task of mapping is left to the Web developer and
>>> they would need to develop it for all possible media formats and all
>>> possible naming schemes in order to get to a standard naming.
>>> I think the media subsystem should do a best effort and then leave the
>>> Web developer to sort out the hard problems.
>>  I agree.
> OK, so then we also have to define that mapping, or should it be per
> container? Do we need it for Ogg too? What if the UA can't guess what role
> "KTV" should be mapped to, should it expose the empty string or just "KTV"?

That mapping can only be done per container, so is probably outside
HTML5, though we could do it for the two main container foramts in
use: MPEG-4 and Ogg.

Yes, Ogg is in the process of defining such headers and will likely
take inspiration from what we decide here, so it will support this,

If the mapping cannot be established, the given string should just be
handed through such that the Web developer can try to make sense of

We should probably add these rules to the document.

Received on Thursday, 4 March 2010 02:59:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:33 UTC