Re: TextTrackCue discussions

+1


On Tue, Jul 23, 2013 at 10:26 AM, Brendan Long <self@brendanlong.com> wrote:

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