Re: TextTrackCue contructor API change

On Mon, Apr 1, 2013 at 4:19 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> After the recent changes to the HTML spec and the WebVTT spec where we've
> made TextTrack and TextTrackCue more generic to deal with different types of
> text track cue file formats, I have some concerns about backwards
> compatibility.
>
> Before the change, we had defined TextTrackCue as follow
>
> enum AutoKeyword { "auto" };
> [Constructor(double startTime, double endTime, DOMString text)]
> interface TextTrackCue : EventTarget {
>   readonly attribute TextTrack? track;
>
>            attribute DOMString id;
>            attribute double startTime;
>            attribute double endTime;
>            attribute boolean pauseOnExit;
>            attribute DOMString vertical;
>            attribute boolean snapToLines;
>            attribute (long or AutoKeyword) line;
>            attribute long position;
>            attribute long size;
>            attribute DOMString align;
>            attribute DOMString text;
>   DocumentFragment getCueAsHTML();
>
>            attribute EventHandler onenter;
>            attribute EventHandler onexit;
> };
>
> Now, after the change, it is:
>
> 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;
> };
>
> This means in particular that the TextTrackCue() constructor does not exist
> any longer and a TextTrackCue cannot be instantiated any more, but only its
> derived interface such as WebVTTCue() can.
>
> I am concerned because the major browsers have implemented the
> TextTrackCue() constructor already [1] (actually: I am not sure what Firefox
> is doing, because they are implementing this right now.).  The
> TextTrackCue() constructor basically created WebVTT cues and people are
> already using TextTrackCue() to create WebVTT cues programmatically [2].
>
> Is this a problem that we should deal with or should we just deprecate the
> TextTrackCue() constructor?
>
> I know this is likely a question for the HTML WG and the WHATWG, but since
> people on this list are likely to have used the TextTrackCue() constructor
> before, I wonder what their thoughts about it are.

I would avoid breaking everything that uses TextTrackCue, so I'm curious why
wouldn't we keep a TextTrackCue constructor with minimal functionality for:
i) pages making use exclusively of metadata cues
ii) pages that display videos only with minimal display functionality
(bottom of the video, centered).

While for ii) we need to add back the "text" attribute to
TextTrackCue, i) works with just the attributes and event listeners
that the TextTrackCue interface offers now.

The two categories wouldn't make use of any specific features that
WebVTT, TTML or other formats have to offer.

Victor

Received on Monday, 1 April 2013 16:32:11 UTC