- From: Philip Jägenstedt <philipj@opera.com>
- Date: Sat, 20 Feb 2010 16:45:07 +0800
- To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
- Cc: "Eric Carlson" <eric.carlson@apple.com>, "Geoff Freed" <geoff_freed@wgbh.org>, "HTML Accessibility Task Force" <public-html-a11y@w3.org>
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. -- Philip Jägenstedt Core Developer Opera Software
Received on Saturday, 20 February 2010 08:45:56 UTC