Re: TextTrackCue discussions

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?

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.


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

Received on Saturday, 7 September 2013 00:05:39 UTC