Re: [media] Moving forward with captions / subtitles

I have tried to summarise everything we have agreed on in
http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations . Could you
please make your changes there directly and just report back here on
them in case there is something controversial?

I think we're in the stage where we all agree on the principle
approach and are filling in the meat, which shouldn't be too
controversial any more.

* I agree with giving <track> and end tag (not sure how to put that
into the spec).
* The <track> element already has a @media attribute - we just need to
add some examples to the wiki page.
* Please fill in the necessary state changes to the media element as
you implement things, since I think that's when we will realise the
implications.
* I think if no track in a trackgroup is enabled, they should all stay
disabled unless some browser preferences for the user say otherwise.
* agree with everything else

Cheers,
Silvia.

On Thu, Feb 18, 2010 at 3:31 AM, 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?
>  + I also assume that if I set the enabled property on one track in a group
> all of the others are automatically disabled?
>  + Do we enable the first track in a group if none match?
>   + 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?
>
> On Feb 16, 2010, at 9:49 PM, Silvia Pfeiffer wrote:
>
> Agreed. I think that confirms the above proposal?
>
> I'm curious what Eric and Geoff think about this now?
>
>   We are getting there ;-)
>
> eric
>
>

Received on Wednesday, 17 February 2010 23:54:05 UTC