Re: TextTrackCue discussions

On Mon, 16 Sep 2013 04:57:35 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> OK, we've come all the way round back to what I proposed in
> http://lists.w3.org/Archives/Public/public-html/2013Aug/0152.html ,
> but with s/GenericCue/UnparsedCue/  and VTTCue not inheriting from
> UnparsedCue.
>
> It seems that we now have agreement on this from several people
> including voices from Opera, Mozilla, and Chrome, but with concerns
> raised from Apple and Microsoft.
>
>
> Here are some remaining open issues from the discussion:
>
> * what is the browser supposed to do for a UnparsedCue on a track with
> @kind="captions" ?

Just expose it to scripts?

> * could / should we enforce that UnparsedCue is always the
> TextTrackCue interface for @kind="metadata" ?

I don't think we should. For WebVTT, one might want a metadata track to  
download but not render, and still want to use the WebVTT-specific stuff  
(e.g. the cue settings).

> * to allow a browser to expose in-band text tracks as UnparsedCue when
> it doesn't want to render the cues, we need to change the algorithm to
> expose in-band text tracks at
> http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#steps-to-expose-a-media-resource-specific-text-track
> : the text track's @kind always has to be "metadata" and the semantics
> need to become part of the "text track in-band metadata track dispatch
> type". Is this the preferred approach?

I don't have an opinion about this point.

-- 
Simon Pieters
Opera Software