Re: TextTrack API changes

On Wed, Apr 24, 2013 at 3:23 PM, Silvia Pfeiffer

> Firstly note that there never was a getCueAsText() API. If mpeg2 requires
> one, then that would be specific to a Mpeg2Cue API and I recommend against
> adding it to TextTrackCue.

That was just a typo.

> I'm prepared to add the .text and getCueAsHTML() interfaces to
> TextTrackCue if there is a definition of another XXXCue interface that has
> these. For example SCCTrackCue could define these, assuming the track was a
> 708 track and converted to SCC.
Since these were already defined on TextTrackCue without explicit
definition of their use with another format, and the language explicitly
abstracted this fact, then it is not required to define any other mapping
in HTML5.

Please restore these two members as they were previously defined on

> Until then, it is better to have these return undefined in new subclasses,
> which can only happen if they are not given on TextTrackCue.
This isn't true for getCueAsHTML() which could return 'undefined' in an
un-overridden base class. However, you are correct for text. Consequently,
I suggest changing to using null instead of undefined for both text and
getCueAsHTML() in the base TextTrackCue class absent an override.

> Silvia.
>  On 25 Apr 2013 08:05, "Glenn Adams" <> wrote:
>> On Wed, Apr 24, 2013 at 2:43 PM, Simon Pieters <> wrote:
>>> On Wed, 24 Apr 2013 18:25:22 +0200, Bob Lund <>
>>> wrote:
>>>  We've already implemented in-band captions for MPEG-2 TS where
>>>> getCueAsHTML returns a valid doc fragment for Cues containing 708 captions.
>>>> We've also implemented a UA that exposes all other MPEG-2 TS  text track
>>>> data as Base64 encoded text via getCueAsText for text tracks not recognized
>>>> by the UA. This is to provide Web applications with the opportunity to
>>>> handle text track formats not supported by the UA. There is at least one
>>>> 3rd party Web app developer that wants to make use of this feature.
>>> Since the specification for .text and .getCueAsHTML() are defined in
>>> terms of WebVTT, it would be useful with a proposed specification for these
>>> features for MPEG-2 TS 708 captions and for unsupported tracks.
>> The current language under [1] states:
>> "The text attribute, on getting, must return the raw text track cue text<>
>>  of the text track cue<>
>>  that the TextTrackCue<>
>>  object represents. On setting, the text track cue text<>
>>  must be set to the new value.
>> The getCueAsHTML() method must convert the text track cue text<>
>>  to a DocumentFragment<>
>>  for the script's document<'s-document>
>>  of the entry script<>,
>> using the appropriate rules for doing so. For example, forWebVTT<>,
>> those rules are the WebVTT cue text parsing rules<>
>>  and the WebVTT cue text DOM construction rules<>
>> . [WEBVTT]<>
>> "
>> The first of these (text), is expressed independently of VTT; the second
>> (getCueAsHTML) is also written generically, "using the appropriate rules".
>> This covers non-VTT uses by delegating the definition of "appropriate
>> rules" to other specifications.
>> I do agree that it would be useful to add language specifying what the UA
>> should do if the text track format's rules are either unknown or not
>> supported. In this regard, I agree with Silvia that text should resolve to
>> undefined (or perhaps null) -- I have no preference. For getCueAsHTML(),
>> the same could apply.
>> [1]
>>> P.S. It would be helpful if you could use proper quoting in your emails.
>>> Thanks.
>>> --
>>> Simon Pieters
>>> Opera Software

Received on Wednesday, 24 April 2013 22:47:45 UTC