W3C home > Mailing lists > Public > public-html@w3.org > July 2013

Re: TextTrackCue discussions

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 27 Jul 2013 00:30:00 +1000
Message-ID: <CAHp8n2nQkK6KkX8o2i7kUnPR5e46zQ2H9EV7kL4nAaU5feD75g@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Brendan Long <self@brendanlong.com>, HTML WG LIST <public-html@w3.org>
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 don't see a
reason why a browser would implement support for a cue format without
also making that support available to JavaScript developers.

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

Received on Friday, 26 July 2013 14:30:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:34 UTC