Re: TextTrack API changes

We're still having a technical discussion and Simon from Opera doesn't seem
to agree with the proposed back-change.
Please take any process issues to the admin mailing list.
Regards,
Silvia.

On Fri, Apr 26, 2013 at 1:01 PM, Glenn Adams <glenn@skynav.com> wrote:

> Silvia,
>
> I don't know why you continue arguing this point. A number of members
> (CableLabs, Cox, Microsoft) have asked that you revert the change to move
> text and getCueAsHTML(), and to restore them to TextTrackCue.
>
> These exist in 5.0 and they should continue to exist in 5.1. There is no
> consensus to change things as you propose, at least for these two interface
> members, which means reverting to the status quo. You can't simply make a
> backward incompatible change like this because hixie likes the idea. If the
> WG says its OK, that's another thing, but the WG has not been asked.
>
> Regards,
> Glenn
>
>
>
> On Thu, Apr 25, 2013 at 7: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.
>>
>>
>>    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?
>>
>> Thanks,
>> Silvia.
>>
>
>