- 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