- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 9 Aug 2013 22:34:16 +1000
- To: public-html <public-html@w3.org>
On Fri, Aug 9, 2013 at 5:44 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Tue, Jul 23, 2013 at 1:16 PM, Silvia Pfeiffer > <silviapfeiffer1@gmail.com> wrote: >> 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 >> ... >> }; > > > Note: changes have been applied to the HTML5.1 spec > https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851#c24 > http://www.w3.org/html/wg/drafts/html/master/single-page.html#texttrackcue > > For those that want to follow the spec fork, see WHATWG bug: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22903 > > WebVTT bug for removing text from VTTCue is at: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=22905 The WebVTT bug has been resolved. Further note: changes have been applied also to the HTML5.0 CR editor draft since it better reflects implemented reality and keeps specs in sync. Regards, Silvia.
Received on Friday, 9 August 2013 12:35:19 UTC