Re: TextTrackCue discussions

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

Cheers,
Silvia.

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