Re: TextTrackCue discussions

On Sat, Jul 27, 2013 at 12:39 AM, Glenn Adams <glenn@skynav.com> wrote:
>
> 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.

Yes there is. It identifies what algorithm is being used to interpret
the content that is in .text .
The sub-interface decides what algorithm is being used.
If we put getCueAsHTML() on TextTrackCue object, a JS developer would
never be able to tell which formats will be parse-able by
getCueAsHTML(), since that information would be hidden in the
algorithm - and it could be multiple formats.


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

That's the idea.


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

That's not enough (even if TextTrack.type existed).
Knowing the mime type of the file/track that has been read gives you
information on the encapsulation - and sometimes information about the
cue format. But, e.g. in WebVTT, a cue could have any type of content,
so the mime type is not sufficient - in particular when it comes from
a media file.

Silvia.

Received on Friday, 9 August 2013 05:01:16 UTC