- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 18 Feb 2010 17:42:10 +1100
- To: 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 Thu, Feb 18, 2010 at 4:49 PM, <philipj@opera.com> wrote: > On Thu, 18 Feb 2010 00:31:17 +0800, Eric Carlson <eric.carlson@apple.com> > wrote: > >> >> On Feb 17, 2010, at 12:00 AM, Philip Jägenstedt wrote: >> >>> On Wed, 17 Feb 2010 15:10:06 +0800, Silvia Pfeiffer >>> <silviapfeiffer1@gmail.com> wrote: >>> >>>> Maybe we have converged? >>> >>> Yes, and for the record this is what I think we agree on: >>> >>> <track> is used to reference an external text track. >>> >> Although we are only talking about external text tracks at the moment, I >> think we will be talking about other media types soon enough (eg. audio >> description) so I would say >> >> <track> is used to reference an external track. >> >> >>> <trackgroup> is used to group several tracks which are mutually >>> exclusive. Often they will have the same role="", but this isn't necessarily >>> so. >>> >>> Your example with active changed to enabled: >>> >>> <video src="video.ogv"> >>> <track src="cc.en.srt" srclang="en" role="CC" enabled> >>> <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> >>> >>> <track> is a void element (no end tag), if there any reason to think that >>> it would ever need child elements then now is the time to give it an end >>> tag. >>> >> I think we will need an end tag to allow <track> to have <source> >> elements for non-text media formats, for example audio description tracks, >> as long as we don't have a mandated format. >> >> One thing we are missing here is the "media" attribute. All of the >> examples we have used so far have selected alternates based on language but >> we also need to be able to consider a user's accessibility needs when >> choosing between track alternates. I believe that a content author should be >> able to describe a track with exactly the same media query syntax we are >> developing to describe movies. >> >> Another major topic we haven't talked about is how external tracks affect >> the movie's readyState and networkState. For example, if a movie's readState >> is HAVE_FUTURE_DATA and the user or a script enables a track for the first >> time, the readyState should drop back to HAVE_METADATA. I don't think this >> will be difficult, but we need to spell out all of the state changes >> thoroughly. > > > >> 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. I think Eric has already considered using this API for both, tracks embedded and external to the media resource. Also, in MPEG there is the construct of groups, too. So maybe we need to introduce that in the API somehow? >> + 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? No, I think we should refrain from that. The trackgroup has no semantic meaning other than grouping tracks together to be activated mutually exclusively. It's like a radio group. Using type, language or role on the trackgroup is just a simplified way or expressing that all track elements share the same value on those attributes, IMO. For example, @track and @role could both be on the trackgroup element and the the tracks inside don't have to all repeat it. >> + I think that a media query that evaluates to "false" means it *must* >> not be enabled because it is not appropriate for the user's environment, so >> should setting enabled to true on such a track just fail? > > I agree, possibly throwing NOT_SUPPORTED_ERR or some other exception. Ok, added. Cheers, Silvia.
Received on Thursday, 18 February 2010 06:43:13 UTC