RE: TextTrack API changes

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<mailto:B.Lund@cablelabs.com>> wrote:
+1

From: <Vickers>, Mark Vickers <mark_vickers@cable.comcast.com<mailto:mark_vickers@cable.comcast.com>>
Date: Wednesday, April 17, 2013 11:21 AM
To: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>>, public-html <public-html@w3.org<mailto:public-html@w3.org>>
Subject: Re: TextTrack API changes
Resent-From: <public-html@w3.org<mailto: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<mailto:glenn@skynav.com>> wrote:



On Sun, Apr 7, 2013 at 11:42 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com<mailto: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.