- From: Glenn Adams <glenn@skynav.com>
- Date: Tue, 7 May 2013 19:44:22 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.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>
- Message-ID: <CACQ=j+cbRH-Nn899w21z-4RcUgi6Ane5Jt3MC2nfP2g2jyeUtQ@mail.gmail.com>
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; 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. 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. On Tue, May 7, 2013 at 2:17 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>wrote: > On Tue, May 7, 2013 at 7:25 PM, Simon Pieters <simonp@opera.com> wrote: > >> On Tue, 07 May 2013 11:04:50 +0200, Silvia Pfeiffer < >> silviapfeiffer1@gmail.com> wrote: >> >> But if you mean by >>>> >>>> >>>> [[ >>>> previously it was possible to construct a cue of any type and append it >>>> to >>>> a track with interpretation of cue content done by JavaScript >>>> ]] >>>> >>>> that it was possible to construct a WebVTT cue with cue content of a >>>> different format and interpret the cue content with JavaScript, then >>>> that >>>> is still possible with new WebVTTCue(). >>>> >>> >>> >>> Right. >>> >> >> OK, good. >> >> >> But since it's no longer a WebVTTCue, but a generic cue, then it >>> doesn't make sense to call it WebVTTCue. >>> >> >> If the use case is covered, let's not introduce new weaker APIs because >> the name doesn't make sense. >> >> >> Also, since we won't be using >>> getCueAsHTML(), the generic Interface of TextTrackCue (plus an added >>> .text >>> or .content attribute) is sufficient. >>> >> >> Is the premise that some user agents will support the TextTrack API but >> not WebVTT? > > > Maybe. But more importantly, they may support other formats, for some of > which they may not have a parsing algorithm to convert cues to HTML, but > will only expose the cue content to JS. Further, JS authors will want to > create TextTrackCues in other formats for which the WebVTT parsing > algorithm doesn't apply. > > For example, Bob indicated that they have an implementation that exposes > text track cues from MPEG-2 files in a TextTrack with TextTrackCue.text > containing the content of the cue. > http://www.cablelabs.com/specifications/CL-SP-HTML5-MAP-I02-120510.pdfsays to expose the cue as a UTF-16 string, or if it's binary as Base64. > > > Another example: with the old TextTrackCue API, JS authors could do: > > cue = new TextTrackCue(0,2,"<region xml:id="r1" tts:origin="10px 100px" > tts:extent="300px 96px" /> <body xml:id="b1"> <div xml:id="d1"> <p > xml:id="p1">Text 1</p> </div> </body> </region>"); > > (which is a TTML cue in intermediate form as per > http://www.cwmwenallt.com/ttml/TTMLmapping.htm). > > cue.getCueAsHTML() applies the WebVTT parsing algorithm to this, which in > this example actually returns "Text 1", but that is by sheer chance, since > it's not actually a WebVTT cue. > > Silvia. >
Received on Wednesday, 8 May 2013 02:45:11 UTC