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

Re: [media] Moving forward with captions / subtitles

From: Philip Jägenstedt <philipj@opera.com>
Date: Sat, 20 Feb 2010 16:45:07 +0800
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Eric Carlson" <eric.carlson@apple.com>, "Geoff Freed" <geoff_freed@wgbh.org>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u8e3xhvnatwj1d@philip-pc>
On Fri, 19 Feb 2010 16:39:09 +0800, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Fri, Feb 19, 2010 at 6:00 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Fri, 19 Feb 2010 13:43:19 +0800, Eric Carlson  
>> <eric.carlson@apple.com>
>> wrote:
>>> On Feb 17, 2010, at 9:49 PM, philipj@opera.com wrote:
>>>> On Thu, 18 Feb 2010 00:31:17 +0800, Eric Carlson  
>>>> <eric.carlson@apple.com>
>>>>>  Some questions and thoughts, in no particular order:
>>>>> +  I assume that if I use our track API to examine the track tracks  
>>>>> in a
>>>>> trackgroup, the one chosen from among a group of alternates is  
>>>>> enabled, and
>>>>> the others are not?
>>>> What does enabled mean here? Since the MediaTracks API doesn't  
>>>> reflects
>>>> the concept of groups, the mapping is open for debate. I think we  
>>>> should
>>>> either reflect groups in some way, or we should simply expose all  
>>>> tracks
>>>> in all groups (enabled or not) and setting .enabled=true on a track
>>>> should
>>>> implicitly disable the others in the same group.
>>>  We should definitely expose all tracks, whether or not they are in a
>>> group. We could expose group, but what could a script do with it?
>> It would be good if a script can tell if enabling a track will disable
>> others, so that it doesn't walk through the list and try to enable all
>> tracks and is then surprised by the results. There is a workaround for
>> <trackgroup><track> (look at the DOM tree), but what about embedded  
>> tracks?
>>>>> + Do we enable the first track in a group if none match?
>>>> I don't think so, but we haven't discussed the track selection  
>>>> algorithm
>>>> much at all. I suppose it should first find the the first track with  
>>>> the
>>>> enabled="" attribute in each group and enable that. But do we also  
>>>> want
>>>> an
>>>> enabled attribute on the group itself that performs selection based on
>>>> media type, language, role etc?
>>> The whole point of <trackgroup> is to mark some number of tracks that  
>>> are
>>> alternates of one another, so the *user agent* can choose which one is  
>>> most
>>> appropriate to enable based on conditions on the user's machine (user
>>> preferences, machine characteristics, etc). If we are just going to  
>>> allow
>>> the user to specify which one is enabled, why bother with the grouping  
>>> at
>>> all?
>> It would be useful even without a track selection algorithm as it would
>> allow the UA and scripts to create appropriate menus and the UA can
>> guarantee that at most 1 track in the same group is enabled.
>> Still, I agree that we should have a track selection algorithm that  
>> takes at
>> least media into account like for <source> resource selection. I'll note
>> that I'm less than optimistic about automatic language selection being
>> useful, because UA language is too often set to something inappropriate.
> I'm thinking out loud here.
> Instead of doing a <trackgroup> element, we could also introduce an
> extra attribute that groups tracks together in a group. Similar to how
> radiobuttons are grouped together by name (e.g.
> http://www.felgall.com/javatip2.htm). Then we lose the beauty of
> avoiding replicating attribute values, but so be it. Everything in a
> group inside a media resource would then also share the same value for
> that, then the javascript could address a group by that
> attribute/javascript API. Maybe...

I'm not thrilled about having to come up with a name for each group. The  
multi-language subtitle case becomes quite ugly:

   <track group="bla" ...>
   <track group="bla" ...>

Where "bla" is any string and means nothing.

Philip Jägenstedt
Core Developer
Opera Software
Received on Saturday, 20 February 2010 08:45:56 UTC

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