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: Wed, 17 Feb 2010 16:49:16 +1100
Message-ID: <2c0e02831002162149s18ca10b2pa9f23187b4b041b3@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Geoff Freed <geoff_freed@wgbh.org>, Eric Carlson <eric.carlson@apple.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Wed, Feb 17, 2010 at 4:31 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 17 Feb 2010 03:20:41 +0800, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Wed, Feb 17, 2010 at 1:55 AM, Philip Jägenstedt <philipj@opera.com>
>> wrote:
>>> In other words, is it role="" alone that determines grouping or does the
>>> <track><source> nesting have some impact?
>> It's not identical because in this case you can have all SUBs active
>> at the same time, while in the existing markup only one of the
>> subtitles would be active at any point in time.
> So in other words role="" has *no* influence over which tracks are mutually
> exclusive, it is only the <track><source> nesting that creates group of
> mutually exclusive tracks.

So far I have only regarded "role" as a valid means of creating
groups, but I'd be more than happy to retract that and make it more
flexible in the way that you are proposing: any tracks can be grouped
and thus made mutually exclusive.

> That makes <trackgroup><track> and
> <track><source> almost identical apart from naming and the minimized form.
> In both cases:
> The inner element references an external text track, possibly with a
> language and role.

Yes. And if used without a grouping element, they are not mutually
exclusive, but can be potentially active together. Notice how that
required introduction of an "active" attribute.

> The outer element makes the children mutually exclusive. Language and role
> may be specified on this element as well, in which case it is inherited by
> the children.

Yes, makes the children mutually exclusive, but the partner tracks
still parallel and potentially active together. So, the children will
actually also need an @active attribute.

> For the inner element, I think both <source> and <track> are OK names.
> <source> has the upside of being an existing element, while the downside is
> that it requires the outer element to not conflict with the sources of
> <audio>/<video>.

Yeah, I haven't made up my mind yet whether choosing the same name is
an advantage or disadvantage.

> For the outer element, I think <track> is a very bad name, as it doesn't
> represent a track at all. <trackgroup> is a bit more verbose, but is exactly
> what it claims to be.

You mean for the grouping element? Right now, the grouping and the
track element are regarded as the same - one with and one without
attributes. But I guess we can take on your way of naming things and
regard not the grouping element as a track, but instead the insides,
which I said before that I agreed with you on the principles there.

So, maybe this could mean:

<video src="video.ogv">
   <track src="cc.en.srt" srclang="en" role="CC" active>
   <track src="tad.en.srt" srclang="en" role="TAD">
   <trackgroup role="SUB">
      <track src="subs.de.srt" srclang="de">
       <track src="subs.sv.srt" srclang="sv">
       <track src="subs.jp.srt" srclang="jp">

the CC, the TAD, and one of the SUB tracks can be active together.

I think this may be the compromise we are after?

> The minimized form of <track><source> (omitting <source>) makes all tracks
> parallel while the minimized form of <trackgroup><track> (omitting
> <trackgroup>) makes all track mutually exclusive.

Yes, I think that was the main difference between our proposals.

> When it comes to UI, I think <trackgroup><track> is better because it
> reflects exactly what a sensible menu nesting could look like, while the
> minimized form of <track><source> would have a less direct mapping (or a
> menu with checkboxes or similar).
> We could also completely drop the nesting and introduce a grouping attribute
> on <track>, but I don't think that would be better than either existing
> proposal.

Agreed. I think that confirms the above proposal?

I'm curious what Eric and Geoff think about this now?

Received on Wednesday, 17 February 2010 05:50:09 UTC

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