Re: TextTrackCue discussions

On 10 Aug 2013 05:08, "Glenn Adams" <glenn@skynav.com> wrote:
>
>
> 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.]

FYI: the last CR heartbeat already had that removed and there were no
objections.

Silvia.