Re: TextTrack API changes

To add to that, we've not *replaced* TextTrackCue with WebVTTCue, but we
have reorganised TextTrackCue as an abstract cue interface and created
WebVTTCue only in the WebVTT spec. Note also that <track> continues to
exist as is and will continue to take WebVTT in its @src attribute (as well
as TTML in IE10).

I hope that addresses your concerns?

Thanks,
Silvia.

On Tue, Apr 23, 2013 at 10:51 AM, Glenn Adams <glenn@skynav.com> wrote:

> There is no part of this change that entails creating a new element (tag)
> for different tag formats. Rather, this change improves the definition of
> some of the text track API interface to move VTT specifics out of the HTML5
> spec. This is entirely appropriate since it is expected that TTML (and
> other formats) will be used for time text track content. In fact I believe
> IE supports TTML to some extent (though I'm not familiar with the details
> of this support).
>
> On Mon, Apr 22, 2013 at 12:26 PM, Jerry Smith (WINDOWS) <
> jdsmith@microsoft.com> wrote:
>
>>  I have some concerns about these changes.  They create a new element
>> that is specific to a file format.  Format specifics like this are normally
>> abstracted away.  For instance, for images we don’t have <jpegimage>,
>> <pngimage> etc…  It would be very inconsistent to have WebVTT variants for
>> TextTrack.****
>>
>> ** **
>>
>> What are the plans for other captioning formats?  Would we similarly
>> propose having a ttmptextcue object?****
>>
>> ** **
>>
>> Jerry****
>>
>> ** **
>>
>> *From:* Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
>> *Sent:* Wednesday, April 17, 2013 5:26 PM
>> *To:* Bob Lund
>> *Cc:* Mark Vickers @ Comcast; Glenn Adams; public-html
>>
>> *Subject:* Re: TextTrack API changes****
>>
>> ** **
>>
>> I will apply this to HTML5.0 next week if there are no objections.
>> Cheers,
>> Silvia.
>>
>> ****
>>
>> On Thu, Apr 18, 2013 at 3:28 AM, Bob Lund <B.Lund@cablelabs.com> wrote:**
>> **
>>
>>  +1****
>>
>> ** **
>>
>> *From: *<Vickers>, Mark Vickers <mark_vickers@cable.comcast.com>
>> *Date: *Wednesday, April 17, 2013 11:21 AM
>> *To: *Glenn Adams <glenn@skynav.com>
>> *Cc: *Silvia Pfeiffer <silviapfeiffer1@gmail.com>, public-html <
>> public-html@w3.org>
>> *Subject: *Re: TextTrack API changes
>> *Resent-From: *<public-html@w3.org>
>> *Resent-Date: *Wednesday, April 17, 2013 11:22 AM****
>>
>> ** **
>>
>>  I'd very much support this change as it will significantly improve
>> TextTrack. Though, I think it should be made to both 5.0 & 5.1 or neither,
>> to avoid backwards-incompatibility. ****
>>
>> ** **
>>
>> Thanks,****
>>
>> mav****
>>
>> ** **
>>
>> On Apr 8, 2013, at 2:26 PM, Glenn Adams <glenn@skynav.com> wrote:****
>>
>>
>>
>> ****
>>
>> ** **
>>
>> On Sun, Apr 7, 2013 at 11:42 PM, Silvia Pfeiffer <
>> silviapfeiffer1@gmail.com> wrote:****
>>
>>  Hi all,****
>>
>> Recently, I cherry-picked some changes to the TextTrack API from the
>> WHATWG repository into the HTML5 specification.
>>
>> In particular, I am referring to these patches:
>>
>> ** Split TextTrackCue into an abstract TextTrackCue interface and a
>> WebVTT-specific interface WebVTTCue. Makes it easier to use TextTrack with
>> other file formats.
>>
>> https://github.com/w3c/html/commit/586ae3996fdce5d9f71cbe57a08759fce7b26d8f
>> WHATWG: 98cdbf20015b11ae7febc581280c3ce02dcd800e (7742)
>>
>> ** Split more WebVTT-specific things into the WebVTT spec. This also
>> makes some normative changes to HTML for handling non-WebVTT cue types, but
>> that shouldn't affect any existing implementations.
>> https://github.com/w3c/html/bdae138d123ddb73586eb8d7f39761ec93e3aa28
>> WHATWG: 0776094323b3f44cbf88eb9f023f4b12c3a6b6a9 (7748)
>>
>> The aim of these patches was two-fold:
>>
>> Firstly, they provide for a cleaner cut between the WebVTT specification
>> and the HTML specification. This was in preparation for a removal of the
>> WebVTT text from the source file from which the HTML specification is
>> created such that the WebVTT specification can now be edited separately
>> (see
>> https://dvcs.w3.org/hg/text-tracks/raw-file/default/webvtt/webvtt.html).
>>
>> Secondly, these changes make the TextTrack API abstract and thus more
>> easily extensible to other file formats such as TTML.
>>
>> The downside of the changes is that TextTrackCue is now an abstract
>> interface without a constructor (instead, the WebVTT spec provides the
>> WebVTTCue constructor). This breaks existing implementations of the
>> TextTrackCue interface in webkit-based browsers (including blink) and in
>> presto. IIUC, Mozilla and IE are not supporting TextTrackCue yet. Also,
>> analysis on the webdevdata collection suggests that the TextTrackCue
>> constructor is not used much on the Web yet, so this is still a good time
>> to break the interface (see
>> http://lists.w3.org/Archives/Public/public-texttracks/2013Apr/0006.html).
>>
>> While I have right now only applied these changes to HTML5.1, I am
>> considering applying them to HTML5.0 as well if presto, webkit and blink
>> decide to change their implementation and gecko and trident decide to
>> support the new specification. I am looking for advice on such a move.***
>> *
>>
>>  ** **
>>
>> Thanks for doing this. I think this makes this functionality more useful
>> and more consistent with existing MIME type independent interfaces. Cox
>> supports these changes.****
>>
>>  ****
>>
>>  ** **
>>
>>    ** **
>>
>
>