Re: TextTrack API changes

On Thu, Apr 25, 2013 at 8:33 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> Glenn,
>
> I am an editor of the HTML specification and while HTML5.1 is still an
> Editor's draft, I can make changes that address bugs and that I think will
> be implemented because they make sense, even if they are not backwards
> compatible. The particular change under discussion is one that you have
> yourself pursued to make the <track> element and TextTrack less dependent
> on WebVTT. The change that I applied to HTML5.1 supported that move.
>
> I am happy for the discussion that we have around the change, because it
> was suggested to backport that change to HTML5 (which, incidentally, hasn't
> happened yet). Changes to HTML5 that are not editorial are indeed more
> complicated, which is why I seeked WG feedback. This process has not been
> finished yet, so I don't understand why you are attacking me for the work
> that is done, diligently and thoroughly.
>

First, I am not attacking you. I am asking you to revert a change for which
there are objections. Yes, I support moving truly VTT specific APIs out of
TextTrackCue, but these two members are not VTT specific, and are written
in a manner to abstract the differences in actual text track format.


> While you and two others are now disagreeing with a part of the change
> that was made, Simon from Opera has agreed with that change. I want to
> continue this discussion until we find a consensus position. Providing
> specifications for TextTrackCue for other formats than WebVTT is part of
> that process.
>

You are suggesting that it is possible to find a consensus to make your
proposed change in the face of objections from members. I will suggest it
is not. You propose a backwards incompatible change. This is not something
that should be implemented in your editorial work in the face of member
objections. The correct option for you is to revert the change, then ask
the matter to be brought to the WG for consideration. After due
consideration, if the WG decides it is best to make this change, then it
will be made.

However, at this time, you appear to be attempting to usurp the role of the
WG in making substantive changes, which is not part of your role as editor.


>
> There are no change proposals involved at this stage - it is merely a
> discussion on the technical mailing list. If you want to go through the
> change proposal process, please follow the complete process as described in
> http://dev.w3.org/html5/decision-policy/decision-policy.html .
>

Precisely. You are making substantive changes without a CP and without WG
approval. This is fine when there are no objections, but that is not the
case here.

It is not necessary to further discuss the technical merits of this change
with Opera in the face of these objections. That is something the WG should
undertake, not the editors.


>
> Regards,
> Silvia.
>
>
> On Fri, Apr 26, 2013 at 1:11 PM, Glenn Adams <glenn@skynav.com> wrote:
>
>> Silvia, you don't have carte blanche to make backwards incompatible
>> changes. Period. I don't imagine why you might think you do.  We have
>> objections to this change. How far do you want to escalate this? Just say
>> OK, and revert it, then we can stop discussing it. For your info, it is not
>> the onus of the objectors to convince you not to make this change. The onus
>> is on you to convince the rest of us that a backward incompatible change is
>> justified. And you haven't done that. The Zero Change Proposal wins.
>>
>> G.
>>
>>
>> On Thu, Apr 25, 2013 at 8:07 PM, Silvia Pfeiffer <
>> silviapfeiffer1@gmail.com> wrote:
>>
>>> 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.
>>>>>
>>>>
>>>>
>>>
>>
>