Re: Resolving TextTrackCue issues

On 6 September, 2013 at 5:26:19 AM, Philip Jägenstedt (philipj@opera.com) wrote:
On Fri, Sep 6, 2013 at 4:56 AM, Rick Eyre <rick.eyre@hotmail.com> wrote:  
> 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.  

Assuming that you will implement the abstract TextTrackCue (no  
constructor or text property) and VTTCue in Gecko, do you also see a  
need for a third interface? What formats do you plan to support that  
would use it?  

Philip  


We'd like to support the abstraction in order to be compliant with spec. There are no plans for Gecko to support any other formats. From WebVTT's viewpoint there isn't a need for a third interface, but we will support it if there is one to be compliant.

Rick