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: Wed, 17 Feb 2010 14:40:50 +0800
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Geoff Freed" <geoff_freed@wgbh.org>, "Eric Carlson" <eric.carlson@apple.com>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u79d6cj1atwj1d@philip-pc>
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:
>>>> 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.

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.

>> 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...

>> 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  

>> 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">
>    </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.

>> 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?

As am I, and anyone else who has managed to follow the thread this far...

Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 17 February 2010 06:41:31 UTC

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