Re: TextTrackCue discussions

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