Re: TextTrack API changes

On Mon, 29 Apr 2013 10:25:35 +0200, Glenn Adams <glenn@skynav.com> wrote:

>> Similarly, if it is useful to construct cues for a specific format in  
>> JS,
>> it should define a constructor like WebVTTCue() does for WebVTT.
>>
>
> It is not clear to me that it is particularly important to expose a
> constructor for cues of any particular type. As currently defined, it is
> not the client JS that creates cue instances, but the internal
> implementation of a text track decoder.

For WebVTT, the WebVTTCue() constructor is for client JS, not for the  
internal implementation. If a format does not need client JS to be able to  
construct cues, then a JS-exposed constructor is not necessary.

>> From what I can tell, a constructor was exposed only to provide a means  
>> to
> programmatically construct a text track via JS,

Yes.

> but this seems an odd
> corner case.

I believe there were use cases for this (probably mostly for the metadata  
kind, though).

> By analogy, it is sort of like providing a FrameList on video and audio
> tracks, and then allowing the application to construct Frame objects. As  
> we
> know, this is not necessary to play back video or audio streams, and it
> doesn't seem particularly needed to playback (render or expose) text  
> track
> streams.
>
>
>>
>> That said, I don't object to moving back .text and .getCueAsHTML() if it
>> is shown that most or all formats need them. As far as I can tell, it  
>> has
>> so far been shown that most formats need .text but not .getCueAsHTML().
>
>
> I do expect that, at least for TTML streams, a specific mapping to HTML
> fragments is quite feasible. Indeed, it is a work item underway in the  
> TTWG
> to define such a mapping, and a very early straw man draft was published  
> a
> while back at [1].

I agree it is feasible for TTML.

> [1] http://www.cwmwenallt.com/ttml/TTMLmapping.htm


>> Having a property available but not return something useful is bad for
>> feature checking in JS. For instance, if a UA supports TTML but does not
>> support serializing TTML cues to HTML, it would be nice to be able to  
>> check
>> for that with e.g.:
>>
>> var supported = 'getCueAsHTML' in TTMLCue.prototype;
>
>
> Tying this functionality to a cue constructor seems odd, particularly as  
> I
> point out above that many (most) cue instances will be constructed
> internally using not necessarily exposed constructors, i.e., a cue object
> will simply be accessible in a text track cue list without knowing  
> anything
> more about it other than the metadata exposed on the track object (e.g.,
> track kind, language, and so on).

I don't understand what is odd about it. That most cues are not  
script-created doesn't mean that a particular design intended for  
script-created cues is odd. That's like saying that  
document.createElement() is odd because most elements are created by the  
HTML parser.


>> It is quite unusual for methods that usually return a value to return
>> undefined (more common to return null). In any case, returning null or  
>> the
>> empty string makes it ambiguous whether the feature is unavailable or
>> whether the cue is empty, which is bad.
>
>
> I agree that returning 'undefined' is not as good as returning 'null'.  
> For
> example, Node.nodeValue [2] dereferences a value that depends upon the
> "context object", and returns null when there is no suitable defined  
> value.
>
> [2] http://www.w3.org/TR/domcore/#dom-node-nodevalue


-- 
Simon Pieters
Opera Software

Received on Monday, 29 April 2013 08:43:39 UTC