Your conclusion is incorrect. We have had a generic TextTrackCue API defined for some time, with nothing tying its use only to WebVTT. It has already been indicated that some implementers have already made specific use of .text and getTextAsHTML() in contexts not related to VTT. I will have to object to moving these two members if it is pursued further. 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 Wednesday, 24 April 2013 20:57:46 UTC