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 22:34:16 +1000
Message-ID: <CAHp8n2mzV6aseYNnq2LhjZoEcSMavqt1_BqFaUzMq0a78mgyJg@mail.gmail.com>
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

Received on Friday, 9 August 2013 12:35:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:34 UTC