This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I've added the Constructor and the text attribute back on the TextTrackCue object. See https://github.com/w3c/html/commit/1e84a5b2c6c16322c277ed2784689d779f5a173e I'll remove the text attribute from VTTCue next. My theory is that JS devs would like to construct generic (i.e. non-VTT) TextTrackCue objects with text content to add to a TextTrackList and TextTrack and have the browser manage them. See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851#c24 This bug is to inform you of this fork and see if you want to follow.
This makes no sense, as per my comments in bug 21851. It's bad design. If browsers unaccountably decide to implement this anyway, I'll update the spec, but in the meantime, this is just a bad idea.
It makes the TextTrackCue API workable with the inBandMetadataTrackDispatchType [1] of the TextTrack API: a browser needs to be able to expose the content of the cues of an in-band track of an unsupported cue format somewhere - the TextTrackCue.text attribute is the right place. In any case: I just wanted to make sure you were aware of the fork - I didn't expect this bug to be resolved any differently. [1] http://www.whatwg.org/specs/web-apps/current-work/#dom-texttrack-inbandmetadatatrackdispatchtype
At the request of simonp, cross-posting from <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/-VHGnuNNUxM>: I don't think that keeping the TextTrackCue constructor and text property makes a lot of sense after TextTrackCue has been stripped of its WebVTT semantics. As far as I can tell, a TextTrackCue created by script can't be rendered at all, since it doesn't have any rendering rules. In other words, I think the WHATWG spec makes more sense here.
(In reply to comment #3) > At the request of simonp, cross-posting from > <https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/- > VHGnuNNUxM>: > > I don't think that keeping the TextTrackCue constructor and text property > makes a lot of sense after TextTrackCue has been stripped of its WebVTT > semantics. As far as I can tell, a TextTrackCue created by script can't be > rendered at all, since it doesn't have any rendering rules. In other words, > I think the WHATWG spec makes more sense here. If you agree with Ian, let's take this discussion to the W3C and bug 21851, where you'd like to see the change happen. ;-)
Spec fork has been removed, see https://github.com/w3c/html/commit/580e7e6f98fbd82586aa7e894efbe8c16b99701f