- From: Philip Jägenstedt <philipj@opera.com>
- Date: Fri, 6 Sep 2013 11:26:19 +0200
- To: Rick Eyre <rick.eyre@hotmail.com>
- Cc: public-html <public-html@w3.org>
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