W3C home > Mailing lists > Public > public-html@w3.org > April 2013

Re: TextTrack API changes

From: Glenn Adams <glenn@skynav.com>
Date: Wed, 24 Apr 2013 13:56:58 -0700
Message-ID: <CACQ=j+csX_fGjNExeBavO1B=xqYATL19VL_YgvQOmRPwVeLEtA@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Bob Lund <B.Lund@cablelabs.com>, "Jerry Smith (WINDOWS)" <jdsmith@microsoft.com>, "Mark Vickers @ Comcast" <mark_vickers@cable.comcast.com>, public-html <public-html@w3.org>
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

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:02 UTC