Re: TextTrackCue discussions

On Mon, Sep 9, 2013 at 7:12 PM, Simon Pieters <simonp@opera.com> wrote:
> 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.



OK, we've come all the way round back to what I proposed in
http://lists.w3.org/Archives/Public/public-html/2013Aug/0152.html ,
but with s/GenericCue/UnparsedCue/  and VTTCue not inheriting from
UnparsedCue.

It seems that we now have agreement on this from several people
including voices from Opera, Mozilla, and Chrome, but with concerns
raised from Apple and Microsoft.


Here are some remaining open issues from the discussion:

* what is the browser supposed to do for a UnparsedCue on a track with
@kind="captions" ?

* could / should we enforce that UnparsedCue is always the
TextTrackCue interface for @kind="metadata" ?

* to allow a browser to expose in-band text tracks as UnparsedCue when
it doesn't want to render the cues, we need to change the algorithm to
expose in-band text tracks at
http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#steps-to-expose-a-media-resource-specific-text-track
: the text track's @kind always has to be "metadata" and the semantics
need to become part of the "text track in-band metadata track dispatch
type". Is this the preferred approach?


Silvia.

Received on Monday, 16 September 2013 02:58:24 UTC