Re: Resolving TextTrackCue issues

On Thu, Sep 5, 2013 at 4:28 PM, Rick Eyre <rick.eyre@hotmail.com> wrote:

> Hey Silvia,
>
> This seems reasonable for Mozilla's implementation. Mozilla has been
> following whatwg's track specification and the newest WebVTT spec.
>
> However, we haven't implemented the abstraction yet. Instead, what
> we have done is expose a single VTTCue class. So the only thing that
> is different from the spec in Firefox that the user will see is that
> VTTCue.prototype !== TextTrackCue.
>
> We do intend to support the abstraction though when there are concrete
> uses of it in the spec.
>

I'm curious if you have an opinion on how to handle the transition w.r.t.
"new TextTrackCue()" vs "new VTTCue()". As currently specified ini HTML5.1
Nightly, the former now constructs a "generic" (non-VTT) cue, while in the
WHATWG ToT, will raise a JS exception (since no constructor is defined).


>
> Rick
>
> > From: silviapfeiffer1@gmail.com
> > Date: Sat, 31 Aug 2013 17:26:51 +1000
> > To: public-html@w3.org
> > Subject: Resolving TextTrackCue issues
>
> >
> > Hi all,
> >
> > Recent changes to the TextTrackCue interface had led to a fork with
> > the WHATWG spec [1] when resolving bug 21851 [2].
> >
> > This caused extensive discussion on blink-dev [3] when an intent to
> > implement was proposed.
> >
> > In the W3C WG we recognize the need for a generic cue interface type
> > with a constructor and a text attribute. It allows browsers to expose
> > cues in text tracks of video or audio files for which browsers don't
> > intend to implement parsers. It also allows JavaScript developers to
> > create time-synchronized data for media elements in any format they
> > require.
> >
> > The discussion on blink-dev exposed that the currently specified
> > solution of bug 21851 [2] in the HTML5 spec is flawed in several ways:
> >
> > (1) TextTrackCue objects that are not fully abstract create hard to
> > debug issues of backwards compatibility due to existing code that
> > assumes "new TextTrackCue()" constructs a cue with VTT semantics;
> > (2) in order to transition old TextTrackCue interface usage to "new
> > VTTCue()", it is better to remove the existing TextTrackCue
> > constructor causing hard failure (easily recognizable) instead of soft
> > failure (more difficult to recognize);
> > (3) the abstract TextTrackCue interface of the WHATWG is desirable for
> > extensibility to non-text-based cue interfaces of the future;
> > (4) the interface fork between the WHATWG and W3C spec should be removed.
> >
> > An alternative resolution to bug 21851 [2] has previously been
> > proposed and discussed: create a new interface that has the text
> > attribute and the constructor and inherits from the abstract
> > interface.
> >
> > This will result in the following interfaces:
> >
> > interface TextTrackCue : EventTarget {
> > readonly attribute TextTrack? track;
> >
> > attribute DOMString id;
> > attribute double startTime;
> > attribute double endTime;
> > attribute boolean pauseOnExit;
> >
> > attribute EventHandler onenter;
> > attribute EventHandler onexit;
> > };
> >
> > [Constructor(double startTime, double endTime, DOMString text)]
> > interface GenericCue : TextTrackCue {
> > attribute DOMString text;
> > };
> >
> > Whether VTTCue will inherit from GenericCue or from TextTrackCue will
> > be resolved in the TextTrack CG once this change has been applied to
> > the HTML5 spec.
> >
> > It is my understanding that this proposed change resolves all the
> > above listed issues. I will therefore apply these changes next week
> > unless there are any further concerns.
> >
> > Regards,
> > Silvia (as HTML spec editor).
> >
> > [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=22903
> > [2] https://www.w3.org/Bugs/Public/show_bug..cgi?id=21851
> > [3]
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/-VHGnuNNUxM/Yibbv2TgDoYJ
> >
>