- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 18 Sep 2013 10:42:36 +0200
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Simon Pieters <simonp@opera.com>, Glenn Adams <glenn@skynav.com>, Brendan Long <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, Eric Carlson <eric.carlson@apple.com>
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