Re: Resolving TextTrackCue issues

On 5 September, 2013 at 7:15:29 PM, Glenn Adams (glenn@skynav.com) wrote:
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).
If the only reason to have a generic non-abstract TextTrackCue object is to not break backwards compatibility then I'd have to say it's not really needed. In both cases the user will have to change their script to use "new VTTCue()" and it will be much easier for the user to recognize that something has changed with the browser, and not their script, when a JS exception is raised.

I think Silvia's recommendation of a GenericCue interface with a text property is a good one, but I don't think that it should be a concrete class. If the Cue doesn't have any rendering rules associated with it then why be able to create it? Rather, the GenericCue can be a branching point for other Cue classes that are text-based and these subclasses can be concrete. It might make more sense to name GenericCue something like "TextBasedCue".

If you really want to get crazy you could rename TextTrackCue to GenericCue and GenericCue to TextCue which VTTCue would implement. Text-based cues would implement the TextCue interface and non-text based cues would implement the GenericCue interface. This makes sense as what we're really working with are cues. This would be a good point to do it at as well since we're going to be breaking current script implementations anyways.

Rick