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; >> 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 > perform TextTrack.addCue(cue) > > >> >> 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? >
Received on Wednesday, 8 May 2013 03:12:05 UTC