- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 23 Feb 2010 07:56:42 +1100
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Eric Carlson <eric.carlson@apple.com>, Geoff Freed <geoff_freed@wgbh.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Mon, Feb 22, 2010 at 3:13 PM, Philip Jägenstedt <philipj@opera.com> wrote: > On Sat, 20 Feb 2010 23:10:21 +0100, Silvia Pfeiffer > <silviapfeiffer1@gmail.com> wrote: > >> On Sat, Feb 20, 2010 at 7:45 PM, Philip Jägenstedt <philipj@opera.com> >> wrote: >>> >>> On Fri, 19 Feb 2010 16:39:09 +0800, Silvia Pfeiffer >>> <silviapfeiffer1@gmail.com> wrote: >>> >>>> On Fri, Feb 19, 2010 at 6:00 PM, Philip Jägenstedt <philipj@opera.com> >>>> wrote: >>>>> >>>>> On Fri, 19 Feb 2010 13:43:19 +0800, Eric Carlson >>>>> <eric.carlson@apple.com> >>>>> wrote: >>>>> >>>>>> >>>>>> On Feb 17, 2010, at 9:49 PM, philipj@opera.com wrote: >>>>>> >>>>>>> On Thu, 18 Feb 2010 00:31:17 +0800, Eric Carlson >>>>>>> <eric.carlson@apple.com> >>>>>>>> >>>>>>>> >>>>>>>> Some questions and thoughts, in no particular order: >>>>>>>> >>>>>>>> + I assume that if I use our track API to examine the track tracks >>>>>>>> in >>>>>>>> a >>>>>>>> trackgroup, the one chosen from among a group of alternates is >>>>>>>> enabled, and >>>>>>>> the others are not? >>>>>>> >>>>>>> What does enabled mean here? Since the MediaTracks API doesn't >>>>>>> reflects >>>>>>> the concept of groups, the mapping is open for debate. I think we >>>>>>> should >>>>>>> either reflect groups in some way, or we should simply expose all >>>>>>> tracks >>>>>>> in all groups (enabled or not) and setting .enabled=true on a track >>>>>>> should >>>>>>> implicitly disable the others in the same group. >>>>>>> >>>>>> We should definitely expose all tracks, whether or not they are in a >>>>>> group. We could expose group, but what could a script do with it? >>>>> >>>>> It would be good if a script can tell if enabling a track will disable >>>>> others, so that it doesn't walk through the list and try to enable all >>>>> tracks and is then surprised by the results. There is a workaround for >>>>> <trackgroup><track> (look at the DOM tree), but what about embedded >>>>> tracks? >>>>> >>>>>>>> + Do we enable the first track in a group if none match? >>>>>>> >>>>>>> I don't think so, but we haven't discussed the track selection >>>>>>> algorithm >>>>>>> much at all. I suppose it should first find the the first track with >>>>>>> the >>>>>>> enabled="" attribute in each group and enable that. But do we also >>>>>>> want >>>>>>> an >>>>>>> enabled attribute on the group itself that performs selection based >>>>>>> on >>>>>>> media type, language, role etc? >>>>>>> >>>>>> The whole point of <trackgroup> is to mark some number of tracks that >>>>>> are >>>>>> alternates of one another, so the *user agent* can choose which one is >>>>>> most >>>>>> appropriate to enable based on conditions on the user's machine (user >>>>>> preferences, machine characteristics, etc). If we are just going to >>>>>> allow >>>>>> the user to specify which one is enabled, why bother with the grouping >>>>>> at >>>>>> all? >>>>> >>>>> It would be useful even without a track selection algorithm as it would >>>>> allow the UA and scripts to create appropriate menus and the UA can >>>>> guarantee that at most 1 track in the same group is enabled. >>>>> >>>>> Still, I agree that we should have a track selection algorithm that >>>>> takes >>>>> at >>>>> least media into account like for <source> resource selection. I'll >>>>> note >>>>> that I'm less than optimistic about automatic language selection being >>>>> useful, because UA language is too often set to something >>>>> inappropriate. >>>> >>>> I'm thinking out loud here. >>>> >>>> Instead of doing a <trackgroup> element, we could also introduce an >>>> extra attribute that groups tracks together in a group. Similar to how >>>> radiobuttons are grouped together by name (e.g. >>>> http://www.felgall.com/javatip2.htm). Then we lose the beauty of >>>> avoiding replicating attribute values, but so be it. Everything in a >>>> group inside a media resource would then also share the same value for >>>> that, then the javascript could address a group by that >>>> attribute/javascript API. Maybe... >>> >>> I'm not thrilled about having to come up with a name for each group. The >>> multi-language subtitle case becomes quite ugly: >>> >>> <video> >>> <track group="bla" ...> >>> <track group="bla" ...> >>> </video> >>> >>> Where "bla" is any string and means nothing. >> >> Yeah, but they will have role="caption" and languages. And with "blah" >> being "Captions", it can be used in the menu as the title for the >> group. > > I agree with this part, we should have an attribute that gives the title for > menu items which override something the browser may derive from role or > language. title="" or name="" perhaps? I think we should have this on both > <trackgroup> and <track>. OK, it seems we already have "name" in the spec for this, so that's good. I'm pretty sure all the other things that were discussed in this thread are covered, too, but I may have missed something (can't be so focused on this in the next week or so). Cheers, Silvia.
Received on Monday, 22 February 2010 20:57:37 UTC