Re: TextTrackCue discussions

On 09/06/2013 06:04 PM, Silvia Pfeiffer wrote:
>> but they need to know the type of cue to get anything useful.
> That's information that the @inBandMetadataTrackDispatchType of
> TextTrack contains.
The information is there, but it's unreasonably difficult to get to.
Would you create an image format where the only way to access pixel data
is a giant if/else block to figure out what kind of image it is? And
what to put in that if/else block can only be determined by reading
several specs? And even after you right it, it will be wrong the next
time someone adds a new format. You're requiring that if a browser can
parse a cue, it can render it, and if the browser can render a cue, it
should have an HTML representation of it, or something that can be made
into an HTML representation.
>> For
>> example, if I want to know the start time of a cue, I can easily get it if I
>> know that the original on-the-wire format was WebVTT. Otherwise, I can hope
>> browser implementers will be consistent, but there's no standard for what
>> that attribute might be named in other cues.
> There is in HTML5: the interface is called TextTrackCue and contains
> the start and end times.
Apparently that was a bad example. The situation is exactly the same
with getCueAsHTML().
>>> What cue formats do you see being supported by browsers as generic parsed
>>> cues without their own special interface?
>> What I want is for all of these special classes to support a common (useful)
>> interface, not a new special class.
>>
>> That's why I proposed this:
>>
>> interface WebVTTCue : ParsedTextTrackCue {
>>     attribute DOMString regionId;
>>     attribute DirectionSetting vertical;
>>     attribute boolean snapToLines;
>>     attribute (long or AutoKeyword) line;
>>     attribute long position;
>>     attribute long size;
>>     attribute AlignSetting align;
>> };
>>
>> interface TTMLCue : ParsedTextTrackCue {
>>     ...
>> };
>>
>> interface CEA708Cue: ParsedTextTrackCue {
>>     ...
>> };
> That looks like 3 identical interfaces, unless you have specific ideas
> what "..." would add?
Sorry, maybe I should have said:
> interface TTMLCue : ParsedTextTrackCue {
>     // Format specific attributes and functions go here
> };
>
> interface CEA708Cue: ParsedTextTrackCue {
>     // Format specific attributes and functions go here
> };
Notice that neither of this classes inherit from WebVTTCue, because
WebVTTCue's special attributes don't necessarily make sense in other cue
formats. Here's a big list
<http://www.w3.org/TR/ttaf1-dfxp/#styling-attribute-vocabulary> of
things that make sense as TTMLCue attributes. Some of them map to WebVTT
attributes, but most don't.

> Right now we have another thread discussing how browsers have
> implemented support for other formats. That thread points to the fact
> that browser have used VTTCue (or rather: the old TextTrackCue) to
> expose several of such formats, thus "prentending" they were VTT
> (because the rendering algorithm of VTT was still used). If it is the
> case for all formats that browsers want to support that they will use
> the same interface and rendering algorithm, we should pull VTTCue back
> into the HTML spec and call it TextCue and make the VTTCue rendering
> algorithm the TextCue rendering algorithm. Then we won't need any
> other interfaces.
Yes, I wrote the other WebKit implementation of text tracks, where we
convert everything into WebVTT. It works pretty well, and should be a
good way to support obscure formats like Kate, but we throw a lot of
information away in the conversion. For important formats like CEA708,
it's entirely reasonable to make a special case so you can present it
perfectly.

If you do want to make WebVTT the only cue format, and put it in the
HTML spec, then that would also resolve my concern about the interfaces
though.
> That's exactly the interface that was proposed with GenericCue (it has
> less VTT-specific attributes), except you're suggesting to add a
> placeholder getCueAsHTML() function there to enforce that every
> further specification of it uses the same named function.
I haven't seen this GenericCue format in the specs, but yes, that's
basically what I want. I find it hard to believe that there's any cue
format that can't be represented in HTML, and I think to make things
reasonable for JS developers, we should force that format to always be
available (although, for efficiency, an implementation could choose to
create it lazily of course).