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: Thu, 18 Feb 2010 11:06:36 +1100
Message-ID: <2c0e02831002171606v6947ff36p6b1600e20430bc1e@mail.gmail.com>
To: Eric Carlson <eric.carlson@apple.com>
Cc: Philip Jägenstedt <philipj@opera.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Thu, Feb 18, 2010 at 1:53 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>> On Feb 17, 2010, at 12:01 AM, Silvia Pfeiffer wrote:
>> 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),

>   In general I prefer using names instead of abbreviations, so I vote for
> "language".

OK, language it is. What about "name"? Maybe we should "name" to both
and leave "id" for what it's used for in HTML/XML generally.

(With "both" I am talking about the two specs at:

>> 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?
>   I think "media" is only useful in markup. It allows the content author to
> describe the characteristics of a resource, and it is used by the UA to
> choose the most appropriate resource from a group of alternates for a user's
> stated needs/preferences.  In other words, I don't think "media" is an
> intrinsic property of the resource so we dont' need to expose it in this API

Ah, so it basically inherits the @media attribute from the video
source. Would it maybe make sense, for reasons of exposing the same
API across internal and external tracks, to return the video source's
@media value in a track's media query if that attribute is read on an
internal track?

Received on Thursday, 18 February 2010 00:07:29 UTC

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