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

Re: [media] a first draft JavaScript API for multitrack media

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 17 Feb 2010 19:01:24 +1100
Message-ID: <2c0e02831002170001k370650a8nff5161a10f070a18@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Further input into this discussion: this time about harmonising the
JavaScript track API with the now further discussed external text
tracks.

We have probably converged on:

  attribute DOMString id;
  attribute DOMString src;
  attribute DOMString role;
  attribute DOMString type;
  attribute DOMString media;
  attribute DOMString srclang;
  attribute boolean      enabled;

as the attributes for a track in the external text track specification,

I would suggest we harmonise the attribute names for the JavaScript
API to these names, too, and therefore:
* rename "name" to "id",
* rename "lang" to "srclang" (instead, we could use "language" in both),

I am not sure about "media", since I wouldn't know how to extract a
media query out of a media resource. But maybe there are some display
hints in media resources that could work for this? Ogg doesn't have
any, but maybe MPEG or QuickTime?

Cheers,
Silvia.


On Wed, Feb 17, 2010 at 5:25 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Wed, Feb 17, 2010 at 4:37 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>> On Wed, 17 Feb 2010 11:44:32 +0800, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>> Hi all, and in particular media subgroup,
>>>
>>> Today we had a phone discussion about the JavaScript API spec and we
>>> realised that we haven't actually specified the list of roles that the
>>> @roles attribute should accept.
>>>
>>> So, I wanted to start a discussion on this with the goal of eventually
>>> reaching a list that we can all agree on to cover the known use cases.
>>>
>>> Let me start by stating that in today's call everyone agreed that we
>>> need to come up with a determined list of values for the roles, so if
>>> you disagree with that, you should speak up now.
>>
>> In all discussions so far role is only an attribute that exists in the
>> markup without having any influence on... well anything. I would like to see
>> suggestions on how UAs should use roles (e.g. in a track selection
>> algorithm) before investing effort in defining them.
>
> There are three particular use cases for UAs of roles:
>
> Firstly, they put all the tracks together in the same css styling
> class, so that you can e.g. switch between subtitles and they are
> still presented in the same way. Tracks with different roles should
> not have the same styling. Of course, this can be overruled by the
> page author, but this applies to the defaults.
>
> Secondly, they provide a means of grouping things together that are
> tightly related and most of the time presented as alternatives (even
> if the media resource had not marked these tracks as alternatives).
>
> Thirdly, they provide a semantic hint for applications/UAs as to what
> is in the track. So, if your browser preference says "always
> automatically activate all subtitles in Swedish" then you can find the
> subtitle track in Swedish.
>
> I thought this was obvious, but it's good to actually state it all. :-)
>
> Cheers,
> Silvia.
>
Received on Wednesday, 17 February 2010 08:02:16 GMT

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