- From: Simon Pieters <simonp@opera.com>
- Date: Tue, 07 May 2013 11:25:45 +0200
- To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
- Cc: "Bob Lund" <B.Lund@cablelabs.com>, "Glenn Adams" <glenn@skynav.com>, public-html <public-html@w3.org>, "Jerry Smith, (WINDOWS)" <jdsmith@microsoft.com>, "Mark Vickers @ Comcast" <mark_vickers@cable.comcast.com>
On Tue, 07 May 2013 11:04:50 +0200, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: >> 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. OK, good. > But since it's no longer a WebVTTCue, but a generic cue, then it > doesn't make sense to call it WebVTTCue. If the use case is covered, let's not introduce new weaker APIs because the name doesn't make sense. > Also, since we won't be using > getCueAsHTML(), the generic Interface of TextTrackCue (plus an added > .text > or .content attribute) is sufficient. Is the premise that some user agents will support the TextTrack API but not WebVTT? -- Simon Pieters Opera Software
Received on Tuesday, 7 May 2013 09:26:34 UTC