Re: TextTrackCue discussions

On Thu, Jul 25, 2013 at 8:00 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> 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 do you mean by "always"? Since VTTCue would override this method to
return a non-null value, and since a browser that understands some other
format may convert it to HTML even without a specialized sub-interface
(like VTTCue) and thus return a non-null value, then "always have to return
null" doesn't make any 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
> )
>

BTW, I find this attribute to be rather poorly named. (1) it is too long,
(2) it is or should not be restricted to metadata kind, (3) it is just as
applicable for other kinds of (text) track formats. It should simply be
renamed to "type" and return a MIME Media Type or null (if unknown).


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