Re: TextTrackCue discussions

I just wanted to pop in and say that I basically agree with Glenn.


On Sun, 08 Sep 2013 06:21:25 +0200, Glenn Adams <glenn@skynav.com> wrote:

>> > You appear to be assuming that one needs a text attribute to mutate a
>> cue.
>> > As you probably know, a DocumentFragment may be mutated. The latter  
>> will
>> be
>> > much more effective in the case of TTML.

Indeed. It means the DocumentFragment has to be live. I would suggest to  
use an IDL attribute annotated with [SameObject] to define it (in TTML2).


> That's not because its the right thing to do or because it should be
> maintained. They implemented it that way because they were working with
> interface definitions (i.e., TextTrackCue in HTML5 CR1) that failed to
> recognize the existence of non-VTT text tracks. In other words, they
> applied the principle "If all you have is a hammer, everything looks  
> like a
> nail."

That seems likely, yeah. Easy to do, but with information loss and is  
obviously "wrong".


> That won't work. The attributes of TextCue as based on VTTCue are not
> sufficient and don't align with the attributes or semantics of other
> formats.

Indeed. For instance I think some formats do pixel-based positioning which  
WebVTT intentionally doesn't support.


>> I'm just trying to find a solution that satisfies all user needs and
>> will be implemented by browsers.
>>
>
> Then I suggest we stop talking and you do the following:
>
> (1) change HTML 5.1 nightly's definition of TextTrackCue to align with
> WHATWG flavor of the day, i.e., remove the constructor and text  
> attribute;
> this solves the spec fork problem for this interface;

Yes.


> (2) define in HTML 5.1 nightly a new interface:
>
> [Constructor(double startTime, double endTime, DOMString text))]
> interface UnparsedCue : TextTrackCue {
>   attribute DOMString text;
> }
>
> if you don't like the name UnparsedCue, then change it to something else;

Yes.

For browsers that only support WebVTT and nothing else, this seems pretty  
useless since the same thing can be achieved using VTTCue as metadata, but  
I agree that it's "wrong" to use that interface for cues that are not in  
fact WebVTT and it's cheap to use a dedicated interface, and moreover  
script authors can use it for media time-aligned stuff that aren't  
captions without having to learn or think about WebVTT, so I support  
having it.


> (3) if you wish, change VTTCue to inherit from UnparsedCue into order to
> inherit its text attribute;

No, I think that's confusing. Scripts should be able to do

    var unparsed = cue instanceof UnparsedCue;

to detect that a cue is not taken care of by the UA. If VTTCue inherits  
 from it, that doesn't work.


> otherwise, define a text attribute directly on
> VTTCue;

Yes.


> If you do these changes, then I think we can stop going round in circles,
> and instead promote that UA implementers adopt these changes.


-- 
Simon Pieters
Opera Software

Received on Monday, 9 September 2013 09:05:57 UTC