Re: TextTrackCue discussions

On Fri, Aug 9, 2013 at 6:34 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> 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.
>

I support this change. However, it should be noted that this is a
substantive, technical change to the CR, due to the removal of the
TextTrackCue.getCueAsHTML() method. We will have to consider whether this
change needs to trigger a new LCWD and subsequent CR2 or can simply go
directly to a new CR2. [I expect there may be other substantive changes in
the CR1 ED as well, so this is probably not the first.]