This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Step 4 of the description of TextTrackCue() needs to be reformulated in a manner that is independent of the use of WebVTT. At present, the following language appears: "Let cue's text track cue text be the value of the text argument, and let the rules for its interpretation be the WebVTT cue text parsing rules, the WebVTT cue text rendering rules, and the WebVTT cue text DOM construction rules. [WEBVTT]" Since a text track need not make use of WebVTT, this language is overly constraining, and presumes a specific content format for track cue data. In order to resolve, I propose adding a (possibly optional) MIME media type parameter to TextTrackCue() so that the caller can specify the associated content type semantics. For example, the caller might specify text/vtt if WebVTT semantics apply to the cue, or might specify application/xml+ttml if TTML semantics apply, etc. Using the specified MIME type, the UA can select the appropriate set of rules to associate with the cue. If this parameter were made optional, then the default value might be specified as text/vtt.
an alternative approach would be to not provide a constructor, but instead have a cue creator method on a TextTrack, which has already been bound to a specific content type (and thus would allow inferring the "interpretation rules" that applies to the cue); for example, one could have: interface TextTrack { ... TextTrackCue createCue(float startTime, float endTime, DOMString text) } note that if a constructor is used and a content type is specified at construction time, then it raises the possibility of a mismatch when performing addCue() on an existing track that is associated with a different content type; for example, if one did: track = video.addTextTrack("captions","application/xml+ttml") cue = new TextTrackCue(0,1,"...","text/vtt") track.addCue(cue) should produce an exception on addCue due to content type mismatch; if instead we had: track = video.addTextTrack("captions","application/xml+ttml") cue = track.createCue(0,1,"...") track.addCue(cue) then we never have an incompatibility the present bug is a result of having a standalone constructor that does not take the track into account at construction time (in terms of its content type from which interpretation rules are to be derived)
This is being discussed as part of bug 21851 and will be resolved there. *** This bug has been marked as a duplicate of bug 21851 ***