22903 2013-08-09 07:14:56 +0000 W3C spec fork on TextTrackCue 2013-09-23 09:00:04 +0000 1 1 1 Unclassified WHATWG HTML unspecified PC All VERIFIED FIXED P2 normal Unsorted 21851 1 silviapfeiffer1 ian annacc annacc annevk bdobbs cdouble chris.double franko giles ian lorettaguarino mike Ms2ger philipj singer zcorpan contributor oldest_to_newest 91824 0 silviapfeiffer1 2013-08-09 07:14:56 +0000 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. 91841 1 ian 2013-08-09 19:12:28 +0000 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. 91861 2 silviapfeiffer1 2013-08-10 09:03:36 +0000 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 91885 3 philipj 2013-08-12 12:00:01 +0000 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. 91892 4 silviapfeiffer1 2013-08-12 13:22:28 +0000 (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. ;-) 93632 5 silviapfeiffer1 2013-09-23 09:00:04 +0000 Spec fork has been removed, see https://github.com/w3c/html/commit/580e7e6f98fbd82586aa7e894efbe8c16b99701f