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

Re: TextTrack API changes

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 8 May 2013 07:17:11 +1000
Message-ID: <CAHp8n2kLtX936wfizfvEHKsY=SjnJGqo1XqeHuDFxMQkQ+LS0g@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Bob Lund <B.Lund@cablelabs.com>, Glenn Adams <glenn@skynav.com>, public-html <public-html@w3.org>, "Jerry Smith, (WINDOWS)" <jdsmith@microsoft.com>, "Mark Vickers @ Comcast" <mark_vickers@cable.comcast.com>
On Tue, May 7, 2013 at 7:25 PM, Simon Pieters <simonp@opera.com> wrote:

> On Tue, 07 May 2013 11:04:50 +0200, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> wrote:
>  But if you mean by
>>> [[
>>> previously it was possible to construct a cue of any type and append it
>>> to
>>> a track with interpretation of cue content done by JavaScript
>>> ]]
>>> that it was possible to construct a WebVTT cue with cue content of a
>>> different format and interpret the cue content with JavaScript, then that
>>> is still possible with new WebVTTCue().
>> Right.
> OK, good.
>  But since it's no longer a WebVTTCue, but a generic cue, then it
>> doesn't make sense to call it WebVTTCue.
> If the use case is covered, let's not introduce new weaker APIs because
> the name doesn't make sense.
>  Also, since we won't be using
>> getCueAsHTML(), the generic Interface of TextTrackCue (plus an added .text
>> or .content attribute) is sufficient.
> Is the premise that some user agents will support the TextTrack API but
> not WebVTT?

Maybe. But more importantly, they may support other formats, for some of
which they may not have a parsing algorithm to convert cues to HTML, but
will only expose the cue content to JS. Further, JS authors will want to
create TextTrackCues in other formats for which the WebVTT parsing
algorithm doesn't apply.

For example, Bob indicated that they have an implementation that exposes
text track cues from MPEG-2 files in a TextTrack with TextTrackCue.text
containing the content of the cue.
http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I02-120510.pdf says
to expose the cue as a UTF-16 string, or if it's binary as Base64.

Another example: with the old TextTrackCue API, JS authors could do:

cue = new TextTrackCue(0,2,"<region xml:id="r1" tts:origin="10px 100px"
tts:extent="300px 96px" /> <body xml:id="b1"> <div xml:id="d1"> <p
xml:id="p1">Text 1</p> </div> </body> </region>");

(which is a TTML cue in intermediate form as per

cue.getCueAsHTML() applies the WebVTT parsing algorithm to this, which in
this example actually returns "Text 1", but that is by sheer chance, since
it's not actually a WebVTT cue.

Received on Tuesday, 7 May 2013 21:17:58 UTC

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