Re: TextTrack API changes

On Mon, Apr 29, 2013 at 6:42 PM, Simon Pieters <simonp@opera.com> wrote:

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


There is also an accessibility requirement to be able to render caption
cues anywhere else on a Web page, for which we need to be able to expose
captions and subtitles to JS developers.

Silvia.

 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<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<http://www.w3.org/TR/domcore/#dom-node-nodevalue>
>>
>
>
> --
> Simon Pieters
> Opera Software
>