Re: [media] Moving forward with captions / subtitles

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

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