- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 06 May 2013 15:15:12 +0200
- To: "Bob Lund" <B.Lund@cablelabs.com>, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
- Cc: "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 Mon, 06 May 2013 14:54:15 +0200, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > I've also put together the core of the discussion at > http://www.w3.org/html/wg/wiki/User:Spfeiffe/TextTrackChange with my > current thoughts on how to resolve it. > > Please let me know if I've missed an argument. > > Also, I'm looking for feedback on the suggested changes, which are in > summary: > * add a .content attribute (of type ArrayBuffer) to TextTrackCue to > provide > a generic IDL attribute for the content of a cue What's the use case for .content? > * re-introduce the TextTrackCue constructor The wiki page says [[ 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 ]] This is false. It was only possible to create WebVTT cues with the TextTrackCue() constructor. (This is an argument against reintroducing it.) [[ re-introduce constructor, but only if there is no getCueAsHTML() API, which would require a default conversion algorithm ]] This doesn't make sense to me. [[ TextTrackCue gets associated with a kind when attached to a TextTrack (e.g. becomes a generic caption or metadata cue) ]] This is no different from WebVTTCue, right? [[ TextTrackCue by itself has no cue type - WebVTTCue has WebVTT as the cue type, which includes an algorithm to convert the content in .content (or .text) to HTML ]] What's the use case for constructing a cue without a cue type? What specifies the behavior of such a cue? > Regards, > Silvia. -- Simon Pieters Opera Software
Received on Monday, 6 May 2013 13:16:16 UTC