Re: TextTrackCue changes

On Thu, Sep 26, 2013 at 4:19 PM, Jerry Smith (WINDOWS) <
jdsmith@microsoft.com> wrote:

>  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.
>

While it is possible, and may be what MSFT did in some versions of IE, it
is not standardized behavior, and, indeed, doing so required ignoring
mandatory semantics in HTML5 CR1, such as requiring the use of WebVTT
semantics with tracks added by text track cue.


> 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.
>

I disagree that keeping these capabilities on the base class is preferred.
I don't see any technical or compatibility requirement for doing so that is
not also available using the newly refactored 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.
>

You can't replace something that wasn't there.  While I understand that
MSFT may have abused the semantics of the former definition of TextTrackCue
to provide access to some MSFT specific notion of a TTML cue, that was done
outside of the standards arena, and without buy-in by the community.

The community is now, finally, adequately coming to terms with a reasonable
design that supports multiple cue formats, including TTML. What MSFT did in
the interim should not serve as a basis for constraining where the
community ends up.


> ****
>
> ** **
>
> 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.
>

Perhaps it would be useful for you to explicitly point at those comments so
we can tell who was saying what. I realize it was me who originally
proposed reverting the removal of the constructor and the text attribute,
but I've moved past that point, and am completely happy with the new
definitions. It is more important in my mind to put this to rest than to
continue going around in circles, and I don't see how your position is
going to help reach closure. In fact, it is adding further delays to
obtaining closure.


> ****
>
> ** **
>
> 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> 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]****
>
> 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> 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.****
>
>  ** **
>