Re: TextTrackCue discussions

On Fri, Jul 26, 2013 at 8:30 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Fri, Jul 26, 2013 at 11:18 PM, Glenn Adams <glenn@skynav.com> wrote:
> >
> >
> > 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)
>
> This is where we have a different understanding: I don't believe a
> browser should support and be able to parse and render a cue format
> without there being a specific XXXCue interface for it.


I didn't say "should", but "may". In any case, this is the point being made
by Brendan, which is that a JS client may not care about a cue
sub-interface when getCueAsHTML() provides an HTML fragment that is
satisfactory.


> I don't see a
> reason why a browser would implement support for a cue format without
> also making that support available to JavaScript developers.
>

If the only purpose of defining a cue specific sub-interface type is to
define a getCueAsHTML() method, then there is little utility in defining
such a sub-interface. There is no need to define a public sub-interface in
this case if TextTrackCue retains the getCueAsHTML() method.


>
> > 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).
>
> I agree with your general sentiment, but "type" is not a good choice
> because the attribute indicates the cue format, not a file format
> (even if these are sometimes the same). I have previously suggested to
> call it "cueFormatHint" and assume its values to be filled from some
> common list. This is an orthogonal issue though.
>

I don't know what "cue format" means. I suppose it could be used to type
values returned from the text attribute. I would expect that the cue format
is tied explicitly to the text track content format, and could be deduced
from a combination of a TextTrack.type (that returns the text track MIME
Media Type) and TextTrack.kind.


>
>
> Cheers,
> Silvia.
>