- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 22 Apr 2013 18:52:27 -0600
- To: "Jerry Smith (WINDOWS)" <jdsmith@microsoft.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Bob Lund <B.Lund@cablelabs.com>, "Mark Vickers @ Comcast" <mark_vickers@cable.comcast.com>, public-html <public-html@w3.org>
- Message-ID: <CACQ=j+c0a+r6UhAfX9PWXDMDEZt2YzGEzgaHCGUpvvPd7sEQFw@mail.gmail.com>
On Mon, Apr 22, 2013 at 6:51 PM, Glenn Adams <glenn@skynav.com> wrote: > There is no part of this change that entails creating a new element (tag) > for different tag formats. > s/different tag formats/different text track 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.**** >> >> **** >> >> ** ** >> >> ** ** >> > >
Received on Tuesday, 23 April 2013 00:53:16 UTC