- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sun, 21 Feb 2010 09:10:21 +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 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. But I am not happy about this solution either. It came from trying to make the inside tracks and the external tracks look similar, so we can have the same API, as e.g. video.tracks["blah"].value . But it's probably not the best approach. I'm just brainstorming here - any ideas welcome! Cheers, Silvia.
Received on Saturday, 20 February 2010 22:11:16 UTC