Re: TextTrack API changes

On 6 May 2013 23:42, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:
>
> On Mon, May 6, 2013 at 11:15 PM, Simon Pieters <simonp@opera.com> wrote:
>>
>> On Mon, 06 May 2013 14:54:15 +0200, Silvia Pfeiffer <
silviapfeiffer1@gmail.com> wrote:
>>
>>> I've also put together the core of the discussion at
>>> http://www.w3.org/html/wg/wiki/User:Spfeiffe/TextTrackChange with my
>>> current thoughts on how to resolve it.
>>>
>>> Please let me know if I've missed an argument.
>>>
>>> Also, I'm looking for feedback on the suggested changes, which are in
>>> summary:
>>> * add a .content attribute (of type ArrayBuffer) to TextTrackCue to
provide
>>> a generic IDL attribute for the content of a cue
>>
>>
>> What's the use case for .content?

Oops, forgot to reply to this. It's to expose the cue content independent
of what type it is supposed to be in and even allow cues of unknown type
(to the UA) that the JS dev knows how to handle. It can also be used by the
UA to provide cues for in-band tracks that it doesn't know how to parse,
but knows how to grab, e.g. a WebVTT metadata track from WebM with cues
containing binary content.

Silvia.

>>
>>
>>> * re-introduce the TextTrackCue constructor
>>
>>
>> The wiki page says
>>
>> [[
>> previously it was possible to construct a cue of any type and append it
to a track with interpretation of cue content done by JavaScript
>> ]]
>>
>> This is false. It was only possible to create WebVTT cues with the
TextTrackCue() constructor. (This is an argument against reintroducing it.)
>
>
>
> You can try on Chrome. Just do cue = new TextTrackCue(0,5,"test"); It
works. Doesn't need to be anything specific.
>
> Maybe my wording was poorly chosen: I should maybe say "construct a cue
of no type".
>
>
>> [[
>> re-introduce constructor, but only if there is no getCueAsHTML() API,
which would require a default conversion algorithm
>> ]]
>>
>> This doesn't make sense to me.
>
>
> I mean by this that if getCueAsHTML() was re-introduced for TextTrackCue,
then a constructor doesn't make sense to me because it needs a conversion
algorithm from cue content to HTML. Since TextTrackCue is created without a
cue type, no such conversion algorithm would exist.
>
>>
>>
>> [[
>>  TextTrackCue gets associated with a kind when attached to a TextTrack
(e.g. becomes a generic caption or metadata cue)
>> ]]
>>
>> This is no different from WebVTTCue, right?
>
>
> Yup. Just some extra information.
>
>
>> [[
>>  TextTrackCue by itself has no cue type - WebVTTCue has WebVTT as the
cue type, which includes an algorithm to convert the content in .content
(or .text) to HTML
>> ]]
>>
>> What's the use case for constructing a cue without a cue type? What
specifies the behavior of such a cue?
>
>
> It has content, which can be retrieved. I'm concretely thinking about
@kind=metadata here, where we only want to retrieve the cue content, but
not render it or do anything else with it. I think this is the basic use
case and TextTrackCue by itself is sufficient for that.
>
> Silvia.