Re: TextTrack API changes

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