Re: TextTrackCue discussions

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?

Philip

Received on Wednesday, 18 September 2013 14:12:09 UTC