Re: TextTrackCue discussions

On Mon, Sep 16, 2013 at 10:29 PM, Simon Pieters <simonp@opera.com> wrote:
> On Mon, 16 Sep 2013 13:29:45 +0200, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>
>>>> * what is the browser supposed to do for a UnparsedCue on a track with
>>>> @kind="captions" ?
>>>
>>>
>>>
>>> Just expose it to scripts?
>>
>>
>> That means changing the semantics of what these kinds mean.
>>
>> http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#attr-track-kind
>> says captions & subtitles are overlaid on the video, descriptions are
>> synthesized as audio, and chapters are displayed as lists, none of
>> which would apply to UnparsedCue.
>>
>> Also, as currently specified, if a UnparsedCue was of @kind=captions
>> and had a @default attribute, it could override an actual TextTrack
>> that had renderable cues.
>>
>> I think the implications of UnparsedCue for @kind != metadata are too
>> far-reaching.
>>
>> I suggest we make it an error to create UnparsedCue for anything but a
>> @kind=metadata TextTrack.
>
>
> It's not clear to me when this situation would happen in the first place.

UnparsedCue can be created by JS and the JS could try to add it to a
track that has a @kind=captions.


> For out-of-band, if the format isn't supported, the spec requires an 'error'
> event on the <track>.

"Out-of-band" can mean JS or <track> supplied. You can't currently
create UnparsedCue from <track>, so indeed that won't be a cause of
trouble.


> For in-band, you said you wanted to expose them as
> kind=metadata, right?

Correct - I don't think browsers will accidentally create UnparsedCue
as a different kind if we specify it in this way.


> That leaves script-created UnparsedCue added to a
> track. Do you want that to throw an exception if kind is not metadata?

That was indeed the suggestion. Is it the right thing to do? Do we
inhibit a useful use case by doing that?



>>>> * could / should we enforce that UnparsedCue is always the
>>>> TextTrackCue interface for @kind="metadata" ?
>>>
>>>
>>>
>>> I don't think we should. For WebVTT, one might want a metadata track to
>>> download but not render, and still want to use the WebVTT-specific stuff
>>> (e.g. the cue settings).
>>
>>
>> Hmm...
>> Are you aware of a use case for WebVTT metadata cues where the cue
>> settings would be useful?
>
>
> They seem useful if you want to render the cues yourself and want to
> support, say, align, but don't want to complicate the cue data format by
> having to store cue settings in there.

OK, I'm not fussed. That'll go into the WebVTT spec anyway. Thanks.


Unless there are any further concerns, I'll prepare patches to
introduce UnparsedCue as discussed.

Cheers,
Silvia.

Received on Monday, 16 September 2013 22:53:00 UTC