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

Re: [media] Moving forward with captions / subtitles

From: Geoff Freed <geoff_freed@wgbh.org>
Date: Tue, 16 Feb 2010 07:28:39 -0500
To: Philip Jägenstedt <philipj@opera.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Eric Carlson <eric.carlson@apple.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <C79FF9A8.9F92%geoff_freed@wgbh.org>
On 2/16/10 3:19 AM, "Philip Jägenstedt" <philipj@opera.com> wrote:

On Tue, 16 Feb 2010 15:46:00 +0800, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:

> On Tue, Feb 16, 2010 at 6:37 PM, Philip Jägenstedt <philipj@opera.com>
> wrote:
>> On Tue, 16 Feb 2010 04:36:09 +0800, Geoff Freed <geoff_freed@wgbh.org>
>> wrote:
>>> GF:  I prefer <trackgroup><track> as well--  grouping tracks by role
>>> makes
>>> the most sense to me. But I'm still confused about one thing after
>>> reading
>>> today's thread.  From this markup, it looks to me like
>>> <trackgroup><track>
>>> also would permit multiple tracks of the same role to appear
>>> simultaneously.
>>>  True?  Playing simultaneous tracks of the same role is still what I'd
>>> prefer (in addition to playing simultaneous tracks of differing roles,
>>> of
>>> course).
>> My idea is that <trackgroup> be used to group mutually exclusive tracks,
>> independently of their roles. I struggle to come up with an example
>> when you
>> would want it, but if you wrap each <track> in its own <trackgroup> then
>> *all* tracks can be enabled simultaneously. It is of course up to the
>> author
>> to make groups that make sense. Power users could override this using
>> user
>> JavaScript or other browser extensions if they really want to.
> I'd actually prefer the opposite functionality - and that would also
> be much more like what is in a media resource:
> <track>s in a list without <trackgroup> can be activated in parallel -
> they are like non-grouped MP4 tracks.
> <track>s inside a <trackgroup> are mutually exclusive - only one of
> them can be activated at any point in time.
> IIUC, that's how grouping works in MP4 and QuickTime and thus applying
> this same principle here seems to make sense to me. Thus, if you
> didn't want tracks to be active together, you'd pack them in a
> trackgroup. Much easier than having to package each single <track> in
> a <trackgroup> to enable them to be active in parallel.

If I understand you, the only difference is the semantics when
<trackgroup> is omitted. We can make either behavior the default. What it
comes down to is what authors actually expect and which case is more
common. I don't know anything about MPEG-4, but I do know that for any
file with multiple text tracks I have opened in any media player (software
or hardware), tracks have been mutually exclusive.

We could sidestep the problem by making <trackgroup> mandatory, although I
think it would be unfortunate if all authors have to pay the price for the
very uncommon (in my guesstimate) practice of having multiple text tracks
active in parallel.

GF:  I don't really think of this as punishing the author.  I do think you're correct in assuming that in most cases, users will want to activate a single track per role.  But I don't think we should rule out simultaneously visible tracks of the same role.  For example, in the case of role=CC, reading a verbatim caption track alongside another caption track that has been edited to a specific reading level would be a useful pedagogical tool.  My point is simply that *users* should be able to determine what tracks are active at any given time.  If I want to see three subtitle tracks at once, why should the author stop me?

Philip Jägenstedt
Core Developer
Opera Software
Received on Tuesday, 16 February 2010 12:29:35 UTC

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