Re: TextTrackCue discussions

On Wed, Jul 24, 2013 at 2:26 AM, Brendan Long <self@brendanlong.com> wrote:
>
> I agree with this, but I think it needs to go (at least) one step further.
> To be usable by HTML authors, we need to present standard interfaces.
> Telling them "you can look at the [some caption format] spec" doesn't help,
> because a given page may not know what the format of a video is. I don't
> look up the JPEG spec whenever I want to display an image.
>
> I actually think the HTML5 CR version is close to perfect, it just contains
> a small amount of style information which is specific to WebVTT. If you
> remove that, you get a good interface for any cue which can be rendered:
>
> interface TextTrackCue : EventTarget {
>   readonly attribute TextTrack? track;
>
>            attribute DOMString id;
>            attribute double startTime;
>            attribute double endTime;
>            attribute boolean pauseOnExit;
>            attribute DOMString text;
>   DocumentFragment getCueAsHTML();
>
>            attribute EventHandler onenter;
>            attribute EventHandler onexit;
> };


All of these are already there, except for the getCueAsHTML() function, see
http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#texttrackcue


> This way, any web author can take any video and look through the cues,
> without knowing or caring what their original format was.
>
> The only thing in this that may not apply to all cues is the html part, but
> we could allow it to be null for cases where cues aren't meant to be
> displayed. Any caption that can be displayed should be able to present its
> content as HTML.

If the browser parses a file and it knows how to parse the cues, it
creates the cues immediately as the specialised object, e.g. VTTCue in
the case of WebVTT.
It will only create TextTrackCue objects when it doesn't know how to
render the cues as HTML.

Thus, if we added a getCueAsHTML() to TextTrackCue, it would always
have to return null, so that makes no sense.

What this would do, though, is to give the browser the chance to parse
a file that it knows how to parse into cues and provide these cues
through a TextTrackCue in .text to the JS developer. Then there is
also the .inBandMetadataTrackDispatchType attribute on TextTrack to
signal what the format of that cue may be if that information may be
available.
(http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#dom-texttrack-inbandmetadatatrackdispatchtype)


> If people want a bunch of other attributes, I'd be happy with that in a
> subclass, but I feel strongly that the primary interface should be useful
> and standardized (in the HTML spec, saying "it will be standardized
> somewhere else" is cheating).

Right, the primary interface is TextTrackCue and it is in the HTML
spec. So we're good.

Cheers,
Silvia.

Received on Friday, 26 July 2013 02:00:54 UTC