- From: <bugzilla@jessica.w3.org>
- Date: Tue, 30 Apr 2013 05:14:54 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851 --- Comment #4 from Ian 'Hixie' Hickson <ian@hixie.ch> --- If you don't know what kind of cue it is, and the cue might return either WebVTT cue text (marked up), base64 data, some random other format, or kittens know what else, then honestly the feature is pointless. I really don't see any value in exposing that, especially given that there's no guarantee anything can be exposed at all. It just doesn't make any sense. What's the use case? If it's just debugging, then just expose the whole object and all its attributes, like console.log does for anything else. The term "TextTrack" is merely meant to distinguish it from AudioTracks or VideoTracks. There's nothing about TextTracks that forces them to be text; they could equally be named "TimedTracks" (indeed at one point they were, we changed it for unrelated reasons). It makes no sense to force every cue format interface to find a string representation. There's no use case for it, there's no need for it (every format can offer its own API), there's no benefit to it. All it does is constrain future format developers. It is no more true that all timed text track formats can expose a string for their cues than it is true that all timed text track formats can expose an X coordinate or a Y coordinate for their cues. I really do not understand why you want this. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 30 April 2013 05:14:56 UTC