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: Fri, 19 Feb 2010 15:00:31 +0800
To: "Eric Carlson" <eric.carlson@apple.com>
Cc: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>, "Geoff Freed" <geoff_freed@wgbh.org>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u8c4e5l4atwj1d@philip-pc>
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.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Friday, 19 February 2010 07:01:27 GMT

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