- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sat, 7 Sep 2013 18:11:22 +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 5:24 PM, Glenn Adams <glenn@skynav.com> wrote: > > On Fri, Sep 6, 2013 at 10:54 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> > wrote: >> >> 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. > > > That would be a waste of effort, i.e., to serialize XML into text only to > expose it to JS which would have to deserialize it from text as XML I follow you up to here - after this, JS would interpret the XML and render it. > to > modify then mutate deserialize by setting text attribute than have > implementation deserialize once more into XML. I don't know why you would need to do all this. > No, that's the last reasonable choice of exposing TTML content. It will be > parsed from XML, mapped to a sequence of TTML ISDs, each an XML document, > then exposed to JS in the latter form. The text attribute will remain null > valued. It would be better to not have .text at all and directly inherit from TextTrackCue. Assuming a browser does *not* implement TTML parsing and rendering, but can extract it from MPEG4 in-band. What would you expose in GenericCue .text ? I was under the impression that it would be TTML fragments as XML documents that would be included in-band in MPEG4, and thus .text would only need to be filled with what is extracted directly from the MPEG4 container. Silvia.
Received on Saturday, 7 September 2013 08:12:11 UTC