Re: TextTrack API changes

I've also put together the core of the discussion at
http://www.w3.org/html/wg/wiki/User:Spfeiffe/TextTrackChange with my
current thoughts on how to resolve it.

Please let me know if I've missed an argument.

Also, I'm looking for feedback on the suggested changes, which are in
summary:
* add a .content attribute (of type ArrayBuffer) to TextTrackCue to provide
a generic IDL attribute for the content of a cue
* re-introduce the TextTrackCue constructor

Regards,
Silvia.


On Mon, May 6, 2013 at 5:41 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Fri, Apr 26, 2013 at 1:04 PM, Bob Lund <B.Lund@cablelabs.com> wrote:
>
>>
>>
>> On Apr 25, 2013, at 8:35 PM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
>> wrote:
>>
>>   On Fri, Apr 26, 2013 at 12:03 PM, Bob Lund <B.Lund@cablelabs.com>wrote:
>>
>>>
>>>    On Fri, Apr 26, 2013 at 1:10 AM, Bob Lund <B.Lund@cablelabs.com>wrote:
>>>
>>>>
>>>>
>>>>   From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
>>>> Date: Wednesday, April 24, 2013 3:23 PM
>>>> To: Glenn Adams <glenn@skynav.com>
>>>> Cc: public-html <public-html@w3.org>, "Jerry Smith, (WINDOWS)" <
>>>> jdsmith@microsoft.com>, Simon Pieters <simonp@opera.com>, Bob Lund <
>>>> b.lund@cablelabs.com>, Mark Vickers <mark_vickers@cable.comcast.com>
>>>>
>>>> Subject: Re: TextTrack API changes
>>>>
>>>    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.
>>>
>>
>>
>>  What do you mean by "provide access to script"? Do you mean: handing
>> over the parsed data to JavaScript? Both .text and getCueAsHTML() do that.
>>
>>
>>  Provide a document fragment.
>>
>
>
> Please note the ongoing discussion in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851 .
>
>
>>     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 you convert the 708 captions into HTML for rendering? That's the
>> specification that I am after... do you have a link to how that is done?
>>
>>
>>  I'll check.
>>
>
> If you could make such a document available, that would be really helpful
> to understand the abstractions that are required.
>
> BTW: I believe it would be good for your specifications to actually
> subclass the TextTrackCue interface for CEA708 and for TTML (if these are
> the formats that you are supporting) and to standardise the algorithms that
> convert CEA708 to HTML (or TTML to HTML) as part of these specifications.
>
> Best Regards,
> Silvia.
>
>