- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 23 Jul 2013 13:18:38 +1000
- To: Public TTWG List <public-tt@w3.org>
FYI, with request for technical input. Regards, Silvia. ---------- Forwarded message ---------- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com> Date: Tue, Jul 23, 2013 at 1:16 PM Subject: TextTrackCue discussions To: public-html <public-html@w3.org> Hi all, I'm getting back to the discussion about TextTrackCue, so we can make some progress on https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851 . The core point of the discussion thread that I started at http://lists.w3.org/Archives/Public/public-html/2013Jun/0037.html was as follows: My opinion was that we should distinguish between Cue objects based on semantics (if they are chapters, descriptions, subtitles etc) and not based on the name of the serialisation file format that provides it (WebVTTCue, TTMLCue), because there are many file formats that will provide the same information to the browser. All my proposed changes hinged on this basic change of design. However, I have received the following feedback from browsers: > I don't see the merit in distinguishing based on semantics, especially if the main motivation is chapters and if for each format, the chapter cues > and normal cues have the same internal representation. Unless there's an actual format with actual implementor interest which requires splitting > of interfaces along the lines you suggest, I think it's just complicating things. That's a fair observation and right now each file format (in particular WebVTT) provides for all the semantics through the same internal markup. I suppose we can continue creating more WebVTT cue settings and markup for all cue kinds for a while before we create something that creates a problem. Also, there is not currently a specification of a different cue JS object (such as TTMLCue). So, let's cross that bridge when we get to it. So, now we can get back to the issue in https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851 . First, I'd like to address Bob's particular use case (http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I02-120510.pdf). IIUC, he has metadata text track cues for in-band MPEG2-TS that he would like to expose to JS as plain text. He could expose them through a VTTCue object, but since the format of the cues in MPEG2-TS is not WebVTT, that makes little sense. Instead, it makes a lot of sense to simply re-introduce the .text attribute on TextTrackCue and for Bob's spec to continue using TextTrack and TextTrackCue, alas without having to worry about TextTrackCue.getCueAsHTML(). A second use case that is similar is that of JS-created metadata tracks. Right now, it's only possible to use "new VTTCue()" to construct a cue in JS, even if it's not going to contain WebVTT markup. It would be easier to just have a constructor on TextTrackCue and be able to put the plain text into the .text attribute. Thus, it might make sense to re-introduce the constructor on TextTrackCue. In summary, the proposed change is as follows: * add .text back onto TextTrackCue * add a constructor back onto TextTrackCue [Constructor(double startTime, double endTime, DOMString text)] interface TextTrackCue : EventTarget { attribute DOMString text; ... }; * remove .text from VTTCue, since it's now inherited [Constructor(double startTime, double endTime, DOMString text)] interface VTTCue : TextTrackCue { // remove text attribute, since it's now inherited ... }; Thoughts? Cheers, Silvia.
Received on Tuesday, 23 July 2013 03:19:26 UTC