Re: TextTrackCue discussions

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

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.


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


>
>
> > On the browser side, we always instantiate the special format-specific
> > class, but on the JS side, we can assume that any presentable cue is
> going
> > to provide this interface, and we don't need to look at the
> format-specific
> > classes unless we need them:
> >
> > interface ParsedTextTrackCue : TextTrackCue {
> >     attribute DOMString id;
> >     attribute double startTime;
> >     attribute double endTime;
> >     attribute boolean pauseOnExit;
> >     attribute DOMString text;
> >
> > DocumentFragment getCueAsHTML();
> >
> >     attribute EventHandler onenter
> >
> > ;
> >     attribute EventHandler onexit; ...
> > };
>
> That's exactly the interface that was proposed with GenericCue (it has
> less VTT-specific attributes), except you're suggesting to add a
> placeholder getCueAsHTML() function there to enforce that every
> further specification of it uses the same named function. We'll see
> what the discussion on the other thread brings.
>
> Silvia.
>
>