- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 17 Feb 2010 16:49:16 +1100
- 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">
</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?
> 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?
Cheers,
Silvia.
Received on Wednesday, 17 February 2010 05:50:09 UTC