On Mon, Apr 29, 2013 at 1:42 AM, Simon Pieters <simonp@opera.com> wrote: > On Mon, 29 Apr 2013 10:25:35 +0200, Glenn Adams <glenn@skynav.com> wrote: > Having a property available but not return something useful is bad for > >> feature checking in JS. For instance, if a UA supports TTML but does not >>> support serializing TTML cues to HTML, it would be nice to be able to >>> check >>> for that with e.g.: >>> >>> var supported = 'getCueAsHTML' in TTMLCue.prototype; >>> >> >> >> Tying this functionality to a cue constructor seems odd, particularly as I >> point out above that many (most) cue instances will be constructed >> internally using not necessarily exposed constructors, i.e., a cue object >> will simply be accessible in a text track cue list without knowing >> anything >> more about it other than the metadata exposed on the track object (e.g., >> track kind, language, and so on). >> > > I don't understand what is odd about it. That most cues are not > script-created doesn't mean that a particular design intended for > script-created cues is odd. That's like saying that > document.createElement() is odd because most elements are created by the > HTML parser. What I mean is that using this suggested approach depends on having a type specific interface object (TTMLCue in this example). However, as I previously cited, it isn't (or shouldn't be) necessary to define a type specific cue interface, particularly if TextTrackCue as defined can serve as a concrete instance class and cue construction is performed internally in the UA.
Received on Monday, 29 April 2013 16:16:24 UTC