Re: TextTrack API changes

On Tue, Apr 30, 2013 at 2:15 AM, Glenn Adams <glenn@skynav.com> wrote:

>
> 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.
>


Right. That's what the new TextTrackCue API does. It doesn't need a
constructor when the browser creates the cue list, which is why it doesn't
have a constructor. But when we need JS to parse a cue format, we need a
format-specific parsing algorithm attached to it and we need a constructor.
Thus, the inheritance.

Silvia.