Re: TextTrack API changes

On Sat, Apr 27, 2013 at 12:46 AM, Glenn Adams <glenn@skynav.com> wrote:

>
>
> On Fri, Apr 26, 2013 at 12:16 AM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>>
>> On Apr 25, 2013, at 10:09 PM, Glenn Adams <glenn@skynav.com> wrote:
>>
>>
>>
>> On Thu, Apr 25, 2013 at 10:01 PM, Silvia Pfeiffer <
>> silviapfeiffer1@gmail.com> wrote:
>>
>>>
>>> You would not want me to revert the whole change. You only want me to
>>> change a small part of it. Why not register a bug and start from there?
>>>
>>
>> At this point, I would prefer that the entire change be reverted, and
>> that you propose which members are to be moved into WebVTTCue, we then
>> discuss that to reach consensus on this set, and then you make a new change.
>>
>> Just to make sure I'm not misunderstood, I generally support a change to
>> move VTT specific members to WebVTTCue, but I don't support changing
>> important members that have been present now for some time, for which
>> implementation activity has already occurred in a non-VTT context, and for
>> which a default behavior can be reasonably defined in the absence of a text
>> track specific defined semantics.
>>
>> Further, just so it's clear that this is not a personal matter, I have
>> the highest regard for your technical editing and appreciate your
>> dedication and results. At the same time, I cannot agree that these changes
>> should be made unilaterally in the face of member objections, and I would
>> urge you to be sensitive to the need to revert changes post facto when
>> member objections arise. It is better in such cases for the WG to make a
>> decision, and then you can implement that decision without the need for
>> unnecessary distractions.
>>
>>
>> While the Chairs do ask for changes to be reverted in exceptional cases,
>> we have usually only applied that policy starting with LC review. 5.1 is in
>> a more open phase of development. If you disagree with a change by the
>> editors, I'd likely suggest one of the following:
>>
>> a) File a bug explaining the problem.
>>
>
> Done. [1]
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21851
>
>

Thanks.



>  b) In the ongoing mailing list discussion, describe specifically what
>> you think the final state of the spec should be and why.
>>
>
> See [1].
>
>
>>
>> While there are times when "revert first, then we can talk about it" is
>> reasonable, it is also the case that reverts can sometimes cause more drama
>> than they resolve. So it's better to keep reverts rare.
>>
>
> I agree. That is why I first stated our preference [2]. That is why I
> originally asked Silvia to restore a subset of the change [3].
>
> [2] http://lists.w3.org/Archives/Public/public-html/2013Apr/0098.html
> [3] http://lists.w3.org/Archives/Public/public-html/2013Apr/0113.html
>
> It has only been because of lack of positive action on the editor's part
> that I now ask for a revert.
>

As a result of the discussion, I agreed that .text should be added back.
The discussion has not been finalized wrt getCueAsHTML().

I am waiting for input from Apple developers and from Bob Lund as to how
they convert 708 to HTML as part of the latter.



> Additional note with chair hat off:
>>
>> I believe the trunk version of WebKit has the ability to expose in-band
>> tracks in non-WebVTT formats.
>>
>
> It did, until Silvia made these changes. It no longer supports that as
> defined. See [1].
>

Just to make sure this is understood: the proposed changes have no
influence on whether in-band tracks can expose their cues or not. If
anything, the proposed change made it easier to expose non-WebVTT cues even
from in-band tracks.

I still expect to resolve this by amicable discussion on the public-html
mailing list.

Best Regards,
Silvia.