Re: TextTrackCue discussions

On Wed, Sep 18, 2013 at 9:59 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> On Tue, Sep 17, 2013 at 10:15 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>> On Tue, Sep 17, 2013 at 2:11 PM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>> On Tue, Sep 17, 2013 at 6:01 PM, Philip Jägenstedt <philipj@opera.com> wrote:
>>>> On Tue, Sep 17, 2013 at 12:52 AM, Silvia Pfeiffer
>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>
>>>>> UnparsedCue can be created by JS and the JS could try to add it to a
>>>>> track that has a @kind=captions.
>>>>
>>>> Why do we need to allow scripts to create UnparsedCue at all? That
>>>> will require some new API surface that isn't needed to solve the
>>>> original use case -- in-band metadata tracks which aren't just a
>>>> special-case of a captioning format.
>>>
>>> It also allows JS devs to create @kind=metadata cues without having to
>>> decide to use a more specific format such as WebVTT.
>>
>> Given that UnparsedCue would be a strict subset of VTTCue, that
>> doesn't sound at all worth adding APIs for.
>
> It avoids developer confusion, which is sufficient reason for me.
>
> Here's another use case: when a browser exposes in-band text tracks
> through a @kind=metadata TextTrack, this allows developers to make
> corrections to the list of cues - add cues if necessary to e.g. fill
> gaps.

It turns out I'm not up to date with what the spec says. addCue and
removeCue are now on the TextTrack interface and take a TextTrackCue,
whereas there used to be a function which created *and* added a cue. I
thought we'd need a new such function, but it's only a question of
whether or not UnparsedCue has a constructor.

I would prefer if UnparsedCue was only ever used for in-band metadata
tracks of an unknown kind, but if browsers are going to expose the
UnparsedCue interface anyway, then exposing a constructor by that same
makes no difference, and would indeed be more consistent.

Philip

Received on Wednesday, 18 September 2013 08:43:04 UTC