Re: TextTrackCue discussions

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

> On Wed, Sep 18, 2013 at 4:05 PM, Glenn Adams <glenn@skynav.com> wrote:
> >
> > 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].
>
> Hmm, this makes we wonder what the property for accessing the data is
> supposed to be. If it's a string, then it requires that the UA at
> least know what the encoding of the text is, which seems like it might
> not be true. RawCue and exposing the data as a typed array .data
> property seems OK to me. The other option is to base64-encode cues
> which are of an unknown encoding, I guess?
>

In the case of RawTTMLCue, it is defined as:

attribute DOMString text

so, yes, the UA would need to at least detect the encoding (of TTML) and
transcode to an ECMAScript String representation (i.e., an array of 16-bit
UTF-16 encoding units).

For a generic RawCue, it would be useful to specify language such as:

If user agent is able to expose the content of a cue in raw text form, and
then that content MUST be serialized as a DOMString (with or without
transcoding). In the case that the native raw format is binary or is
otherwise not able to be serialized as a DOMString, then it SHOULD be
serialized as a BASE64 representation of the raw cue content.