Re: TextTrack API changes

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.
b) In the ongoing mailing list discussion, describe specifically what you think the final state of the spec should be and why.

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.


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. I've asked some of the relevant engineers what we do for the "text" and "getCueAsHTML()" properties in those cases. Hopefully that information will help the technical discussion.

Regards,
Maciej