- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sun, 12 May 2013 09:55:14 +1000
- To: Glenn Adams <glenn@skynav.com>
- Cc: Simon Pieters <simonp@opera.com>, Bob Lund <B.Lund@cablelabs.com>, public-html <public-html@w3.org>, "Jerry Smith, (WINDOWS)" <jdsmith@microsoft.com>, "Mark Vickers @ Comcast" <mark_vickers@cable.comcast.com>
On Wed, May 8, 2013 at 1:11 PM, Glenn Adams <glenn@skynav.com> wrote: > > On Tue, May 7, 2013 at 7:52 PM, Glenn Adams <glenn@skynav.com> wrote: >> >> >> On Tue, May 7, 2013 at 7:44 PM, Glenn Adams <glenn@skynav.com> wrote: >>> >>> Silvia, >>> >>> At this point, I would suggest the following resolution, subject to >>> discussion and agreement: >>> >>> 1. leave TextTrackCue.text in place, with no name change; I agree that adding .text back onto TextTrackCue makes sense to me. >>> 2. move getCueAsHTML() to WebVTTCue; other formats can define an appropriate >>> mapping and necessary partial interfaces on TextTrackCue or a subclass; That's already how it is now. >>> 3. either (1) remove TextTrackCue constructor and define TextTrack.addCue >>> with a content type implied by the content type of the TextTrack (see below) That doesn't make sense to me - TextTrack.addCue(cue) adds a cue to a TextTrack, where the cue has been constructed before. Thus, if you wanted to be able to create a generic TextTrackCue, i.e. one where the content type has not been defined yet and is only interpreted by the content type of the TextTrack, then we still need a constructor for TextTrackCue. This was, in fact, what I proposed. >>> or (2) keep TextTrackCue constructor and add an optional media type >>> parameter; I don't think a media type parameter is necessary. The TextTrackCue can stand on its own as a plain vanilla text-only cue associated with a time interval until an interpretation is necessary. That interpretation is only necessary when it gets associated with a TextTrack through addCue(). >> s/addCue/createCue/ since addCue is defined already meaning something >> other than create a cue >> >>> >>> 4. add an optional media type parameter to HTMLMediaElement.addTextTrack, >>> thus allowing client JS to declare the intended type of any cue created by >>> TextTrack.addCue Hmm... We are now dealing with multiple different "types" here - let's see if they are necessary to expose and how to expose them: * file format of text track: this is the "encapsulation" format in which the cues are delivered, e.g. WebVTT files, TTML files, MPEG files, WebM files -> I don't think this has to be exposed to JS, because we abstract away from the file format in the TextTrack object and the browser does the parsing of the file for us * cue format of the text track: this is the parsing of the cues after extraction from the file, e.g. WebVTT caption cues (as extracted from WebVTT files, MPEG files, WebM files), WebVTT chapter cues, TTML caption cues, MPEG-specific metadata cues -> in the past we have introduced the inBandMetadataTrackDispatchType IDL attribute to expose the type of data that is exposed to JS from a metadata track from inband tracks. I believe we are now talking about doing the same thing for other kinds of tracks coming from inband, <track> or even JS-created. As I don't think anyone has implemented the inBandMetadataTrackDispatchType IDL attribute yet (please let me know if there is an implementation!), we could rename this attribute to cueType and expose the cue type for all cues there. The cueType would be set by the browser when the TextTrack is created from in-band or from parsing a <track> element. In the case of WebVTT from WebM, this is already set to “D_WEBVTT/kind“, where kind is one of SUBTITLES, CAPTIONS, DESCRIPTIONS, or METADATA. The same could be done for WebVTT cues coming from <track>. Do you think the MPEG2 and MPEG4 types as described in [1] would work for this, too? Would they be able to expose the cue format? [1] http://www.w3.org/TR/html5/single-page.html#steps-to-expose-a-media-resource-specific-text-track For JS-created tracks, we'd have a default TextTrack cueType, which may just be plain text. That would work with any kind of track (kind being one of subtitle, caption, metadata, chapter, descriptions). However, when the first cueType is added from a cue that is not just a TextTrackCue, but a more specific cue such as a WebVTTCue, then the cueType of the TextTrack changes to that cueType and cannot be changed again. All TextTrackCues that are not a WebVTTCue will be rejected. Regards, Silvia.
Received on Saturday, 11 May 2013 23:56:02 UTC