RE: TextTrackCue changes

Most of the WebVTT semantic references in HTML5 CR1 are examples, not requirements.

It is possible to implement a TextTrackCue per CR1 that can provide caption cues for either WebVTT or TTML.  Text cues can be provided with enter and exit times, and getCueAsHTML can produce styled cues in HTML form.  I believe keeping these capabilities is preferred and don’t see an argument for removing them, other than Ian’s short comment about doing that being bad design.

The styling attributes are only useful for WebVTT, which means dynamic cues have syntax issues of the type you’ve indicated.  I think there is a valid reason for handling them differently.  I also believe that the DataCue concept may be useful for in-band cues.  My specific objection is regarding removing capabilities for the basic cue object itself, especially with no replacement for TTML.

Sylvia:  My comment about “two people opposing” meant ones that felt the direction created in the fork (that of having a text attribute on the object, etc…) wasn’t correct.  These were essentially two comments advocating closing the fork by removing the capabilities form TextTrackCue, as you’ve subsequently done.

Jerry

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Thursday, September 26, 2013 3:58 PM
To: Jerry Smith (WINDOWS)
Cc: Silvia Pfeiffer; public-html
Subject: Re: TextTrackCue changes


On Thu, Sep 26, 2013 at 3:40 PM, Jerry Smith (WINDOWS) <jdsmith@microsoft.com<mailto:jdsmith@microsoft.com>> wrote:
My wording was imprecise.  I was disagreeing with the commit on the change because it reduces capability on the textTrackCue object that is currently used by websites.  I interpreted Glenn's comments as understanding that, but perhaps I misread him.

I noted Ian's comment about retaining the constructor, the text attribute and (apparently previously removed) getCueAsHTML as being bad design.  As things stand, the generic cue object is the only one defined that supports TTML for these operations.  I don't agree with removing them.

Since there is no defined use of TextTrackCue with TTML cues, either before (HTML5 CR1) or now (HTML5.1 Nightly and WHATWG specs), then I don't understand your objection. That is, for HTML5 CR1, there is:

(1) no defined semantics of TextTrackCue with TTML;
(2) no definition of what TextTrackCue.text might mean with TTML;
(3) no definition of what TextTrackCue.getCueAsHTML might mean with TTML;

further

(4) HTML5 CR1 specified that VTT semantics applied when creating a TextTrack, e.g., see step 5 of addTextTrack under [1]:

"Associate the text track list of cues<http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#text-track-list-of-cues> with the rules for updating the display of WebVTT text tracks<http://www.w3.org/TR/2012/CR-html5-20121217/infrastructure.html#rules-for-updating-the-display-of-webvtt-text-tracks> as its rules for updating the text track rendering<http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#rules-for-updating-the-text-track-rendering>. [WEBVTT]<http://www.w3.org/TR/2012/CR-html5-20121217/references.html#refsWEBVTT>"

Given this, it is unclear what you are disagreeing with, since there never has been a defined use of these APIs with TTML.


Jerry

-----Original Message-----
From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>]
Sent: Thursday, September 26, 2013 3:32 PM
To: Jerry Smith (WINDOWS)
Cc: public-html
Subject: Re: TextTrackCue changes
Hi Jerry,

On Fri, Sep 27, 2013 at 5:57 AM, Jerry Smith (WINDOWS) <jdsmith@microsoft.com<mailto:jdsmith@microsoft.com>> wrote:
> I see two comments opposed to restoring the text attribute and the constructor to the base texttrackcue object.  I am in favor of that, and thought others were as well.  How was this specific topic resolved and committed?  Was there a broader consensus for this change?


Indeed. As a result of the lengthy discussions, they have now been removed from the base TextTrackCue interface and thus also removed the spec fork (Glenn's email points out all the right spec pointers.)

So, what you're asking for has indeed been achieved.

Regards,
Silvia.