Re: TextTrack API changes

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