Re: TextTrack API changes

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;
>    2. move getCueAsHTML() to WebVTTCue; other formats can define an
>    appropriate mapping and necessary partial interfaces on TextTrackCue or a
>    subclass;
>    3. either (1) remove TextTrackCue constructor and define
>    TextTrack.addCue with a content type implied by the content type of the
>    TextTrack (see below) or (2) keep TextTrackCue constructor and add an
>    optional media type parameter;
>
> 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
>


 I prefer the first option in (3) above, since it prevents an author from
> attempting to add a TTML cue to a VTT track, etc.
>

By which I mean that such an attempt would raise an exception, since the UA
knows the media type associated with a track and with a cue, and can check
that they are the same (or compatible) when attempting to


>
> I don't have a strong opinion about what default media type should apply
> if none is specified to addTextTrack. In other words, I could accept
> "text/vtt" as a default.
>
>
Also, if we do end up with both addCue and createCue, then perhaps
addTextTrack should be renamed to createTextTrack for consistency?