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

On Feb 17, 2010, at 12:01 AM, Silvia Pfeiffer wrote:

> 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 think it is important that there be no distinction between external and internal tracks from the perspective of the API, and that this API must work for tracks of any type, so I would strike "external text" from that last sentence. I don't think we disagree about this, but we should be careful as we describe what we are working on.


> 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".


> 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

  Thanks Silvia!

eric

> 
> 
> 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.
>> 
>