Re: TextTrack API changes

On Fri, Apr 26, 2013 at 1:10 AM, Bob Lund <> wrote:

>   From: Silvia Pfeiffer <>
> Date: Wednesday, April 24, 2013 3:23 PM
> To: Glenn Adams <>
> Cc: public-html <>, "Jerry Smith, (WINDOWS)" <
>>, Simon Pieters <>, Bob Lund <
>>, Mark Vickers <>
> Subject: Re: TextTrack API changes
>   Firstly note that there never was a getCueAsText() API.
>  There is getCueAsSource API in
> my mistake on the exact method name.

That is very old. Even in the HTML5 spec (as compared to the HTML5.1 spec
that we are currently discussing) that has been replaced with .text .
getCueAsSource() should only float around in some old implementations of
outdated browsers by now.

>   If mpeg2 requires one, then that would be specific to a Mpeg2Cue API
> and I recommend against adding it to TextTrackCue.
>  The TextTrackCue text attribute as defined here
> is
> fine.


>    I'm prepared to add the .text and getCueAsHTML() interfaces to
> TextTrackCue if there is a definition of another XXXCue interface that has
> these.
>  There is a definition for in-band MPEG-2 TS text tracks here
> that
> is normatively referenced by the DLNA HTML5 Remote UI spec. This defines
> use of the TextTrackCue text and getCueAsHTML attributes.

Thanks! Is this a spec that you are trying to standardize? Is this going
through MPEG?

I can see that several time getCueAsHTML() has to be defined to return
"null" in this document, because you don't need it. That indicates that it
makes sense not to have it on TextTrackCue.

Even for the caption case the document states "getCueAsHTML() returns a
DocumentFragment with an HTML representation of the TextTrackCue text
attribute as defined in [HTML5], if the UA knows how to create such a
representation. Otherwise, getCueAsHTML returns null." - that would only
work for WebVTT captions IIUC.

So, how about we add .text back onto TextTrackCue and leave the
specification of getCueAsHTML() to any inherited Objects?


Received on Friday, 26 April 2013 01:12:37 UTC