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: Mon, 15 Feb 2010 21:04:25 +0800
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Eric Carlson" <eric.carlson@apple.com>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
Message-ID: <op.u756ln0qatwj1d@philip-pc>
On Mon, 15 Feb 2010 19:29:48 +0800, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Mon, Feb 15, 2010 at 6:06 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Mon, 15 Feb 2010 14:41:53 +0800, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>>> lang="" is already inherited,
>>>
>>> Where from? I am confused.
>>
>> The language of a node in HTML depends on the node itself and all  
>> ancestor
>> nodes. [1] In other words lang="" is inherited and I'm saying that if  
>> one
>> motivation for grouping is to save typing then we can let role="" be
>> inherited in the same way.
>
> Actually, I have wondered about @lang before and just forgotten about
> it. I don't think we can use the normal @lang attribute anyway, since
> it specifies the "primary language for the element's contents". In our
> case, we actually want it to specify the language of the resource in
> @src. So, in other such elements it was called @hreflang. We probably
> need to come up with something like this, too.
>
> About inheritance of the value: I agree that that's what is expected
> from the top-level element.

Right you are, @lang probably isn't appropriate here.

>> We've agreed on the basics for a long time, this is all about finding  
>> the
>> appropriate markup/structure to express it, isn't it? I find my
>> <track><source> suggestion confusing because <track> actually contains  
>> many
>> tracks. Also, it makes the nesting mandatory, as <source> cannot be  
>> given as
>> a direct child to <audio>/<video> as that would conflict with the  
>> resource
>> selection algorithm. <trackgroup><track> is intended to address both of
>> these problems.
>
> Oh, I didn't believe we would use <source> as the top-level, but it
> would continue to be track.
>
> So, it would be either:
>
> <track role="SUB">
>   <source src="subtitles.en.srt" lang="en">
>   <source src="subtitles.sv.srt" lang="sv">
>   <source src="subtitles.fr.srt" lang="fr">
>   <source src="subtitles.zh.srt" lang="zh">
> </track>
> <track role="captions">
>   <source src="captions.en.srt" lang="en">
>   <source src="captions.sv.srt" lang="sv">
>   <source src="captions.fr.srt" lang="fr">
>   <source src="captions.zh.srt" lang="zh">
> </track>
>
> when we want just one of the sources be chosen as the subtitle track.
>
> Or it would be:
>
> <track src="caption.en.srt" lang="en" role="CC">
> <track src="subtitles.sv.srt" lang="sv" role="SUB">
> <track src="subtitles.fr.srt" lang="fr" role="SUB">
> <track src="subtitles.zh.srt" lang="zh" role="SUB">
>
> if they were all independent and possible to be activated in parallel,
> just like the grouped tracks above can be active in parallel.

Regardless of the element names, I think that if a minimized form (where  
the inner element is omitted) is allowed it should result in 4 mutually  
exclusive tracks, as this is quite surely the most common case.

> I do like the re-use of <source> since it overlaps with so many
> elements with the existing <source> element - all we need to do is add
> a @srclang attribute (or something similar).
>
> Alternatively, the language could of course always be stuck into the
> @media element with other media queries. However, I'm increasingly
> wondering if the @media element is not just an framework for
> introducing new attributes without making them explicit. But that's
> another discussion altogether.

Since we all seem to be at least somewhat confused, here's a "common" and  
"complex" case expressed in both <track><source> and <trackgroup><track>  
markup. <track> in both forms clearly does *not* mean the same thing. Draw  
your own conclusions about which is better.

Simple case: two subtitle tracks in two different languages:

In <track><source> markup:

<video src="video.ogv">
   <track role="SUB">
     <source src="subs.en.srt" srclang="en">
     <source src="subs.sv.srt" srclang="sv">
   </track>
</video>

In <trackgroup><track> markup:

<video src="video.ogv">
   <track src="subs.en.srt" role="SUB" srclang="en">
   <track src="subs.sv.srt" role="SUB" srclang="sv">
</video>

<trackgroup> is omitted because it is only needed when some tracks can be  
enabled in parallel. If one doesn't like typing role="SUB" twice one can  
use <trackgroup role="SUB">. In practice I think role="" will simply be  
omitted in simple cases like this, if the selection algorithm we define  
allows it.



Complex case: two subtitle tracks and two caption tracks in two different  
languages:

In <track><source> markup:

<video src="video.ogv">
   <track role="SUB">
     <source src="subs.en.srt" srclang="en">
     <source src="subs.sv.srt" srclang="sv">
   </track>
   <track role="CC">
     <source src="cc.en.srt" srclang="en">
     <source src="cc.sv.srt" srclang="sv">
   </track>
</video>

In <trackgroup><track> markup:

<video src="video.ogv">
   <trackgroup role="SUB">
     <track src="subs.en.srt" srclang="en">
     <track src="subs.sv.srt" srclang="sv">
   </trackgroup>
   <trackgroup role="CC">
     <track src="cc.en.srt" srclang="en">
     <track src="cc.sv.srt" srclang="sv">
   </trackgroup>
</video>



Personally, I prefer <trackgroup><track> because it matches what I think  
of as a "track" and the minimized form caters to the common case. Avoiding  
<source> makes it unproblematic to make the grouping element optional, as  
it cannot conflict with the resource selection algorithm for  
<audio>/<video>.

I don't think that making <trackgroup> optional is a must-have feature and  
would probably be OK with <*><source> if we can find a suitable value for  
*.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Monday, 15 February 2010 13:05:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:02 GMT