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

Re: TextTrack API changes

From: Bob Lund <B.Lund@CableLabs.com>
Date: Fri, 26 Apr 2013 02:03:07 +0000
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Glenn Adams <glenn@skynav.com>, public-html <public-html@w3.org>, "Jerry Smith, (WINDOWS)" <jdsmith@microsoft.com>, Simon Pieters <simonp@opera.com>, "Mark Vickers @ Comcast" <mark_vickers@cable.comcast.com>
Message-ID: <CD9F394B.2B7A3%b.lund@cablelabs.com>

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>>
Date: Thursday, April 25, 2013 7:11 PM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>
Cc: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>, 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>>, Mark Vickers <mark_vickers@cable.comcast.com<mailto:mark_vickers@cable.comcast.com>>
Subject: Re: TextTrack API changes

On Fri, Apr 26, 2013 at 1:10 AM, Bob Lund <B.Lund@cablelabs.com<mailto:B.Lund@cablelabs.com>> wrote:

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.

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 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.

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.

No, it is needed for the closed caption type of text track. getCueAsHTML is how script would get access control rendering of the Cue. The reason it is not used for other text track data types, for instance subtitles, is we wanted to minimize the text track types that the UA is required to recognize. However, if a UA CAN render a particular type of text track then getCueAsHTML would be the standard way for script to control rendering, just as was done for closed captions.

It seems to me that it would almost always be the case that a text track format that can be rendered by the UA could use getCueAsHTML to provide access to script.

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.

No, we do that for 708 captions in our implementation.

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

Yes on .text. With regard to getCueAsHTML, you originally asked if there was a text track format other than WebVTT that used it. I have provided an example. I have also provided a rationale for why one could expect most text track formats to want to use getCueAsHTML for textual or graphic captions/subtitles. I'd prefer to see …AsHTML be left with TextTrack.

Received on Friday, 26 April 2013 02:04:21 UTC

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