Re: TextTrack API changes

Hi Simon (and Silvia),

>> I think what Silvia meant is that having .text on WebVTTCue instead of
> TextTrackCue is preferred. I tend to agree

Would you mind providing technical details on this preference? What
are the downsides to making getCueAsHTML() and .text generic? It is
the _Text_Track_Cue_ API after all, and so I see broad potential
applicability. As Silvia pointed out (if I understand well), an
implementation of the API can always return undefined or "" as the
case may be.

Thanks,

-- Pierre


On Wed, Apr 24, 2013 at 1:26 PM, Simon Pieters <simonp@opera.com> wrote:
> On Wed, 24 Apr 2013 16:35:49 +0200, Glenn Adams <glenn@skynav.com> wrote:
>
>> Ah right. Yes, an undefined return value is preferred in that case. Can we
>> just leave these two methods in place on TextTrackCue then rather than
>> moving them?
>
>
> I think what Silvia meant is that having .text on WebVTTCue instead of
> TextTrackCue is preferred. I tend to agree. I also think now is the wrong
> time to argue about on which interface the various members should be,
> because we only have an API for WebVTT so far.
>
>
>>
>> On Tue, Apr 23, 2013 at 10:21 PM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com
>>>
>>> wrote:
>>
>>
>>> I think that is a worse interface than the default "undefined" return
>>> value in JavaScript, because it doesn't allow a JS developer to
>>> distinguish
>>> between when there is really an empty string returned as the actual value
>>> in contrast to that functionality not being available on a text track cue
>>> type. I'd prefer we just leave it as is.
>>>  Silvia.
>
>
> --
> Simon Pieters
> Opera Software
>

Received on Friday, 26 April 2013 18:50:15 UTC