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 18:10:06 +1100
Message-ID: <2c0e02831002162310o4bca34cbk19f0e0d0ee632525@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 5:40 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 17 Feb 2010 13:49:16 +0800, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> 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:
>> 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.
> I didn't mean it as a proposal, I though this followed from how flattening
> the <track><source> example would work. In any case if we agree that
> grouping shouldn't be based (only) on role="" then all is well.

Yup, fine. Happy for that flexibility, which more closely matches what
MPEG/QT do anyway.

>>> 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.
> It's not possible to omit the grouping element in <track><source>, because
> that would put <source> directly as a child of <video>. That's a difference
> in the minimized form, but let's find common ground on the actual
> outer/inner elements first...

Oh, the idea was that the <track> element would work like the <video>
element: it would either have a set of sources or not.

But I'm happy to use trackgroup and track instead in the way proposed.

>>> 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.
> Sure, it's like <select><option selected>, except multiple selection isn't
> possible.

Yup. More like a radiogroup.

>> 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">
>>   </trackgroup>
>> </video>
>> the CC, the TAD, and one of the SUB tracks can be active together.
>> I think this may be the compromise we are after?
> IIUC, the difference here from what I was proposing is that when
> <trackgroup> is omitted, each <track> is implicitly in a group of its own
> and can activated in parallel.


> This requires <trackgroup> to be used in the typical case of multi-language
> subtitles, but I don't think it's unreasonably verbose. It might also be a
> good thing that *not* using <trackgroup> doesn't implicitly put everything
> in a group as in my proposal.


> In any event I think the above is better than <track><source> and am not
> sure if I'd want to change the semantics of the minimized form or not.
> For the record, I like enabled="" better as the on/off-attribute, as it's a
> bit more neutral-sounding.

Ok, done.

Maybe we have converged?

Received on Wednesday, 17 February 2010 07:11:04 UTC

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