W3C home > Mailing lists > Public > public-html-a11y@w3.org > February 2010

Re: [media] Moving forward with captions / subtitles

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 18 Feb 2010 17:42:10 +1100
Message-ID: <2c0e02831002172242y1a17f75erff85b19cf59cd926@mail.gmail.com>
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.

Received on Thursday, 18 February 2010 06:43:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:09 UTC