Re: TextTrack API changes

On Fri, 26 Apr 2013 20:49:26 +0200, Pierre-Anthony Lemieux  
<pal@sandflow.com> wrote:

> Hi Simon (and Silvia),
>
>>> I think what Silvia meant is that having .text on WebVTTCue instead of
>> TextTrackCue is preferred. I tend to agree
>
> Would you mind providing technical details on this preference?

Different formats would need to define different rules for these, so they  
might as well define an interface specific to the format and have .text  
and .getCueAsHTML() there if needed (or getCueAsBitMap or getCueAsBlob or  
getCueAsJSON, if that's more appropriate for the format).

Similarly, if it is useful to construct cues for a specific format in JS,  
it should define a constructor like WebVTTCue() does for WebVTT.

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


> What
> are the downsides to making getCueAsHTML() and .text generic?

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;

> It is
> the _Text_Track_Cue_ API after all, and so I see broad potential
> applicability. As Silvia pointed out (if I understand well), an
> implementation of the API can always return undefined or "" as the
> case may be.

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.

-- 
Simon Pieters
Opera Software

Received on Monday, 29 April 2013 06:27:52 UTC