On Tue, May 7, 2013 at 5:41 PM, Simon Pieters <simonp@opera.com> wrote: > On Mon, 06 May 2013 15:42:16 +0200, Silvia Pfeiffer < > silviapfeiffer1@gmail.com> wrote: > > This is false. It was only possible to create WebVTT cues with the >>> TextTrackCue() constructor. (This is an argument against reintroducing >>> it.) >>> >>> >> >> You can try on Chrome. Just do cue = new TextTrackCue(0,5,"test"); It >> works. Doesn't need to be anything specific. >> > > Chrome implements the old spec where TextTrackCue() creates a WebVTT cue. > The "test" above is parsed using WebVTT parsing rules. The created cue has > WebVTT-specific properties. > True. But for many purposes you can ignore the getCueAsHTML() part of the TextTrackCue API and just use the .text (or as I am proposing: .content) interface to get the data of a cue. When taking away the getCueAsHTML() interface, we don't need to type the TextTrackCue any more. > But if you mean by > > > [[ > previously it was possible to construct a cue of any type and append it to > a track with interpretation of cue content done by JavaScript > ]] > > that it was possible to construct a WebVTT cue with cue content of a > different format and interpret the cue content with JavaScript, then that > is still possible with new WebVTTCue(). Right. But since it's no longer a WebVTTCue, but a generic cue, then it doesn't make sense to call it WebVTTCue. Also, since we won't be using getCueAsHTML(), the generic Interface of TextTrackCue (plus an added .text or .content attribute) is sufficient. Silvia.
Received on Tuesday, 7 May 2013 09:05:37 UTC