Re: TextTrackCue discussions

On Wed, Sep 18, 2013 at 2:42 AM, Philip Jägenstedt <philipj@opera.com>wrote:

> 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.
>

Would it be better to call this interface RawCue or RawTextCue, so that it
doesn't necessarily imply that it is not parsed? This would be useful to
permit a rendered cue interface type (that exposes getCueAsHTML) to inherit
from Raw{Text}Cue in order to provide the text attribute.

I have specified a RawTTMLCue to serve this function (as a base interface
for TTMLCue) in [1].

[1]
file:///Users/glenn/work/w3c/ttml/ttml1-api/Overview.src.html#dfn-intermediate-synchronic-document