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

Re: [media] Moving forward with captions / subtitles

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 23 Feb 2010 07:56:42 +1100
Message-ID: <2c0e02831002221256wbbe9917h23e4eea91cc50ab2@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Eric Carlson <eric.carlson@apple.com>, Geoff Freed <geoff_freed@wgbh.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Mon, Feb 22, 2010 at 3:13 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Sat, 20 Feb 2010 23:10:21 +0100, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Sat, Feb 20, 2010 at 7:45 PM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>> 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:
>>> <video>
>>>  <track group="bla" ...>
>>>  <track group="bla" ...>
>>> </video>
>>> Where "bla" is any string and means nothing.
>> Yeah, but they will have role="caption" and languages. And with "blah"
>> being "Captions", it can be used in the menu as the title for the
>> group.
> I agree with this part, we should have an attribute that gives the title for
> menu items which override something the browser may derive from role or
> language. title="" or name="" perhaps? I think we should have this on both
> <trackgroup> and <track>.

OK, it seems we already have "name" in the spec for this, so that's good.

I'm pretty sure all the other things that were discussed in this
thread are covered, too, but I may have missed something (can't be so
focused on this in the next week or so).

Received on Monday, 22 February 2010 20:57:37 UTC

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