- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sat, 7 Sep 2013 14:54:29 +1000
- To: Glenn Adams <glenn@skynav.com>
- Cc: Brendan Long <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>
On Sat, Sep 7, 2013 at 12:29 PM, Glenn Adams <glenn@skynav.com> wrote: > > On Fri, Sep 6, 2013 at 6:04 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> > wrote: >> >> On Sat, Sep 7, 2013 at 7:11 AM, Brendan Long <self@brendanlong.com> wrote: >> > On 08/30/2013 07:36 PM, Silvia Pfeiffer wrote: >> > >> >> What would be the reason for hiding the actual format that the browser >> >> parsed from the JS developer? Why wouldn't we specify another interface >> >> for >> >> such a parsed format that is actually able to give the JS developer >> >> more >> >> specific information/attributes about the Cue format just like we did >> >> with >> >> VTTCue? >> > >> > Because it's too specific. Right now JS developers can easily get the >> > raw >> > cue data, >> >> The raw cue data is only exposed in the GenericCue interface that we >> are just now proposing, or in the current W3C version of TextTrackCue. >> The WHATWG version of TextTrackCue does not expose the raw cue data. >> >> >> > but they need to know the type of cue to get anything useful. >> >> That's information that the @inBandMetadataTrackDispatchType of >> TextTrack contains. >> >> >> > For >> > example, if I want to know the start time of a cue, I can easily get it >> > if I >> > know that the original on-the-wire format was WebVTT. Otherwise, I can >> > hope >> > browser implementers will be consistent, but there's no standard for >> > what >> > that attribute might be named in other cues. >> >> There is in HTML5: the interface is called TextTrackCue and contains >> the start and end times. >> >> >> >> What cue formats do you see being supported by browsers as generic >> >> parsed >> >> cues without their own special interface? >> > >> > What I want is for all of these special classes to support a common >> > (useful) >> > interface, not a new special class. >> > >> > That's why I proposed this: >> > >> > interface WebVTTCue : ParsedTextTrackCue { >> > attribute DOMString regionId; >> > attribute DirectionSetting vertical; >> > attribute boolean snapToLines; >> > attribute (long or AutoKeyword) line; >> > attribute long position; >> > attribute long size; >> > attribute AlignSetting align; >> > }; >> > >> > interface TTMLCue : ParsedTextTrackCue { >> > ... >> > }; >> > >> > interface CEA708Cue: ParsedTextTrackCue { >> > ... >> > }; >> >> That looks like 3 identical interfaces, unless you have specific ideas >> what "..." would add? > > > TTMLCue will have at least: > > interface TTMLCue { > DocumentFragment getCueAsTTML(); // obtain TTML intermediate synchronic > document (ISD) I would expect that to end up in .text - makes more sense to me. > DocumentFragment getCueAsHTML(); // obtain HTML rendering of TTML ISD > } > > where the first of these allows access to the TTML ISD source (as an XML > node tree), and the second allows access to the mapped HTML rendering of > this source. > > If there is a inherited text attribute, it will return null on get and raise > exception on put. It's a TTML cue, so .text should return TTML... > > I haven't decided if there is a need to expose a TTMLRegion or not. Perhaps > it will be of use, in which case I expect to use a similar string based id > to reference it from TTMLCue.regionId (better named TTMLCue.region) and have > a TTML based TextTrack to expose a TTMLRegionList. > > In this regard, I would expect it be better to define a generic > TextTrackRegion super interface that can be used as the parent interface for > VTTRegion and TTMLRegion. Would be interesting to see the difference between VTTRegion and TTMLRegion... >> >> >> Right now we have another thread discussing how browsers have >> implemented support for other formats. That thread points to the fact >> that browser have used VTTCue (or rather: the old TextTrackCue) to >> expose several of such formats, thus "prentending" they were VTT >> (because the rendering algorithm of VTT was still used). If it is the >> case for all formats that browsers want to support that they will use >> the same interface and rendering algorithm, we should pull VTTCue back >> into the HTML spec and call it TextCue and make the VTTCue rendering >> algorithm the TextCue rendering algorithm. Then we won't need any >> other interfaces. > > > TTMLCue will not use VTTCue semantics, though some implementer may choose to > expose TTML ISDs by translating to VTT, in which case VTTCue would be used. > But that is merely an implementation strategy and doing this presents > certain disadvantages. So please don't reopen the notion of folding VTTCue > back into TextTrackCue. We've moved beyond that (in both HTMLWG and WHATWG > specs). I get a feeling that's what some of the browsers want. It would be good to get clarification on this. Silvia.
Received on Saturday, 7 September 2013 04:55:17 UTC