TextTrackCue discussions

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:17:29 UTC