Difference between revisions of "User:Spfeiffe/TextTrackChange"

From HTML WG Wiki
Jump to: navigation, search
(added suggestion for .content attribute)
(adding more details on TextTrackCue constructor)
Line 116: Line 116:
  
 
Argument against:
 
Argument against:
* ??
+
* ???
  
 
Proposal:
 
Proposal:
 
* re-introduce constructor, but only if there is no getCueAsHTML() API, which would require a default conversion algorithm
 
* re-introduce constructor, but only if there is no getCueAsHTML() API, which would require a default conversion algorithm
 +
* TextTrackCue gets associated with a kind when attached to a TextTrack (e.g. becomes a generic caption or metadata cue)
 +
* 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

Revision as of 12:52, 6 May 2013

Text Track Cue API Changes

Recently, the Text Track Cue API has changed from:

enum AutoKeyword { "auto" };
[Constructor(double startTime, double endTime, DOMString text)]
interface TextTrackCue : EventTarget {
  readonly attribute TextTrack? track;

           attribute DOMString id;
           attribute double startTime;
           attribute double endTime;
           attribute boolean pauseOnExit;
           attribute DOMString vertical;
           attribute boolean snapToLines;
           attribute (long or AutoKeyword) line;
           attribute long position;
           attribute long size;
           attribute DOMString align;
           attribute DOMString text;
  DocumentFragment getCueAsHTML();

           attribute EventHandler onenter;
           attribute EventHandler onexit;
};

to

interface TextTrackCue : EventTarget {
  readonly attribute TextTrack? track;

           attribute DOMString id;
           attribute double startTime;
           attribute double endTime;
           attribute boolean pauseOnExit;

           attribute EventHandler onenter;
           attribute EventHandler onexit;
};

with the addition of a new WebVTT specific text track cue API:

enum AutoKeyword { "auto" };
[Constructor(double startTime, double endTime, DOMString text)]
interface WebVTTCue : TextTrackCue {
           attribute DOMString vertical;
           attribute boolean snapToLines;
           attribute (long or AutoKeyword) line;
           attribute long position;
           attribute long size;
           attribute DOMString align;
           attribute DOMString text;
  DocumentFragment getCueAsHTML();
};

Relevant patches:

The aim of these patches:

  • Remove WebVTT-specifics from the generic TextTrackCue object
  • Create an abstract TextTrackCue API that can be extended to other file formats such as TTML,


Related bugs:


Discussion issues

(1) Removal of .text from TextTrackCue

Argument to re-introduce:

Argument against:

  • there may be timed cue formats that don't expose text, e.g. images, bitmaps or URLs

Proposal:

  • introduce an attribute .content (of type ArrayBuffer) that exposes the content of the cue in its native form


(2) Removal of getCueAsHTML() from TextTrackCue

Argument to re-introduce:

Argument against:

  • there will be many timed cue formats with binary content that will not be converted to a HTML fragment for rendering, e.g. images, bitmaps, data URLs
  • every new format that a UA supports needs an extensive algorithm to convert a cue's content to HTML - this needs to be specified and implemented in the UA and discoverable that it's available - own Object definitions make sense, e.g. TTMLCue API, CEA708CueAPI
  • the MPEG-2 to HTML document defines getCueAsHTML() always as null except where the UA knows how to convert a caption cue to HTML - it makes sense that the UA returns a more appropriate object in these cases, such as WebVTTCue or TTMLCue, such that it is discoverable what type the UA identified

Proposal:

  • no change


(3) Removal of TextTrackCue constructor

Argument to re-introduce:

  • TextTrack.addCue() requires a cue to be constructed in HTML; by removing the constructor, we can only create new cues of a particular type (WebVTTCue only at this point in time)
  • 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
  • not backwards compatible with existing implementations

Argument against:

  •  ???

Proposal:

  • re-introduce constructor, but only if there is no getCueAsHTML() API, which would require a default conversion algorithm
  • TextTrackCue gets associated with a kind when attached to a TextTrack (e.g. becomes a generic caption or metadata cue)
  • 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