Re: TextTrackCue discussions

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.  
For out-of-band, if the format isn't supported, the spec requires an  
'error' event on the <track>. For in-band, you said you wanted to expose  
them as kind=metadata, right? That leaves script-created UnparsedCue added  
to a track. Do you want that to throw an exception if kind is not metadata?

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

-- 
Simon Pieters
Opera Software

Received on Monday, 16 September 2013 12:29:42 UTC