Re: TextTrack API changes

On Sun, Apr 28, 2013 at 11:25 PM, Simon Pieters <simonp@opera.com> wrote:

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

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.

>From what I can tell, a constructor was exposed only to provide a means to
programmatically construct a text track via JS, but this seems an odd
corner case.

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

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


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


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


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


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