Re: TextTrackCue discussions

> My opinion was that we should distinguish between Cue objects based on
> semantics (if they are chapters, descriptions, subtitles etc) and not
> based on the name of the serialisation file format that provides it
> (WebVTTCue, TTMLCue), because there are many file formats that will
> provide the same information to the browser.

> In summary, the proposed change is as follows:
>
> * add .text back onto TextTrackCue
> * add a constructor back onto TextTrackCue
>
> [Constructor(double startTime, double endTime, DOMString text)]
> interface TextTrackCue : EventTarget {
>            attribute DOMString text;
>   ...
> };
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 <http://www.w3.org/TR/2012/CR-html5-20121217/infrastructure.html#eventtarget> {
>   readonly attribute TextTrack <http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#texttrack>? track <http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#dom-texttrackcue-track>;
>
>            attribute DOMString id <http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#dom-texttrackcue-id>;
>            attribute double startTime <http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#dom-texttrackcue-starttime>;
>            attribute double endTime <http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#dom-texttrackcue-endtime>;
>            attribute boolean pauseOnExit <http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#dom-texttrackcue-pauseonexit>;
>            attribute DOMString text <http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#dom-texttrackcue-text>;
>   DocumentFragment <http://www.w3.org/TR/2012/CR-html5-20121217/infrastructure.html#documentfragment> getCueAsHTML <http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#dom-texttrackcue-getcueashtml>();
>
>            attribute EventHandler <http://www.w3.org/TR/2012/CR-html5-20121217/webappapis.html#eventhandler> onenter <http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#handler-texttrackcue-onenter>;
>            attribute EventHandler <http://www.w3.org/TR/2012/CR-html5-20121217/webappapis.html#eventhandler> onexit <http://www.w3.org/TR/2012/CR-html5-20121217/embedded-content-0.html#handler-texttrackcue-onexit>;
> };
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 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).