Re: TextTrackCue discussions

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 to
modify then mutate deserialize by setting text attribute than have
implementation deserialize once more into XML.

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.


>
> >   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...
>

Nope. No need and a waste of effort. See above.


>
>
> >
> > 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.
>

I haven't heard anyone state that they want to have an implementation
detail like this exposed to client script as such. If some browser actually
does this, and I'm not aware of it, though it is certainly possible as an
implementation approach, then I suspect it has more to do with the fact
that the pre-existing definition of TextTrackCue was heavily biased towards
a VTT representation.

Silvia.