Re: TextTrack API changes

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.