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