W3C home > Mailing lists > Public > public-html@w3.org > August 2013

Re: TextTrackCue discussions

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 9 Aug 2013 17:44:29 +1000
Message-ID: <CAHp8n2n=t=F3SQYr5TFWvQOrXTcH_ejZfHv7yzktk6pRVnt_1g@mail.gmail.com>
To: public-html <public-html@w3.org>
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

For those that want to follow the spec fork, see WHATWG bug:

WebVTT bug for removing text from VTTCue is at:

Received on Friday, 9 August 2013 07:45:17 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:04 UTC