Re: Resolving TextTrackCue issues

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

Received on Friday, 6 September 2013 09:26:48 UTC