RE: TextTrack API changes

Silvia;

I've looked at the specs for TextTrackCue and WebVTTCue.  They are quite different.  I'd like to confirm some aspects of this proposed change:


-          It makes TextTrackCue an abstract interface, but preserves the existing TextTrackCue object for compatibility - correct?  Does that suggest TextTrackCue is a base implementation and WebVTTCue a proposed variant?'

-          How will the WebVTTCue affect implementation of the track element itself?  The details of it appear to require changes beyond the que object itself.  If it does, that does not seem a proper way to evolve a standardized element.

Jerry

From: Bob Lund [mailto:B.Lund@CableLabs.com]
Sent: Thursday, April 25, 2013 8:10 AM
To: Silvia Pfeiffer; Glenn Adams
Cc: public-html; Jerry Smith (WINDOWS); Simon Pieters; Mark Vickers @ Comcast
Subject: Re: TextTrack API changes



From: Silvia Pfeiffer <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>>
Date: Wednesday, April 24, 2013 3:23 PM
To: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Cc: public-html <public-html@w3.org<mailto:public-html@w3.org>>, "Jerry Smith, (WINDOWS)" <jdsmith@microsoft.com<mailto:jdsmith@microsoft.com>>, Simon Pieters <simonp@opera.com<mailto:simonp@opera.com>>, Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>, Mark Vickers <mark_vickers@cable.comcast.com<mailto:mark_vickers@cable.comcast.com>>
Subject: Re: TextTrack API changes


Firstly note that there never was a getCueAsText() API.
There is getCueAsSource API in http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#timed-text-tracks; my mistake on the exact method name.

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 http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#text-track-api 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 http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I02-120510.pdf that is normatively referenced by the DLNA HTML5 Remote UI spec. This defines use of the TextTrackCue text and getCueAsHTML attributes.

For example SCCTrackCue could define these, assuming the track was a 708 track and converted to SCC.

Until then, it is better to have these return undefined in new subclasses, which can only happen if they are not given on TextTrackCue.

Silvia.
On 25 Apr 2013 08:05, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:

On Wed, Apr 24, 2013 at 2:43 PM, Simon Pieters <simonp@opera.com<mailto:simonp@opera.com>> wrote:
On Wed, 24 Apr 2013 18:25:22 +0200, Bob Lund <B.Lund@cablelabs.com<mailto:B.Lund@cablelabs.com>> 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<http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#text-track-cue-text> of the text track cue<http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#text-track-cue> that the TextTrackCue<http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#texttrackcue> object represents. On setting, the text track cue text<http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#text-track-cue-text> must be set to the new value.

The getCueAsHTML() method must convert the text track cue text<http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#text-track-cue-text> to a DocumentFragment<http://www.w3.org/TR/2012/CR-html5-20121217/infrastructure.html#documentfragment> for the script's document<http://www.w3.org/TR/2012/CR-html5-20121217/webappapis.html#script's-document> of the entry script<http://www.w3.org/TR/2012/CR-html5-20121217/webappapis.html#entry-script>, using the appropriate rules for doing so. For example, forWebVTT<http://www.w3.org/TR/2012/CR-html5-20121217/infrastructure.html#webvtt>, those rules are the WebVTT cue text parsing rules<http://www.w3.org/TR/2012/CR-html5-20121217/infrastructure.html#webvtt-cue-text-parsing-rules> and the WebVTT cue text DOM construction rules<http://www.w3.org/TR/2012/CR-html5-20121217/infrastructure.html#webvtt-cue-text-dom-construction-rules>. [WEBVTT]<http://www.w3.org/TR/2012/CR-html5-20121217/references.html#refsWEBVTT>"

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] http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#texttrackcue


P.S. It would be helpful if you could use proper quoting in your emails. Thanks.


--
Simon Pieters
Opera Software