- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 16 Sep 2013 13:01:21 +0200
- To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
- Cc: "Glenn Adams" <glenn@skynav.com>, "Brendan Long" <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, "Eric Carlson" <eric.carlson@apple.com>, Philip Jägenstedt <philipj@opera.com>
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
Received on Monday, 16 September 2013 11:01:55 UTC