Re: TextTrack API changes

On 4/29/13 2:42 AM, "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 metadata use cases for JS creating Cues. One could also imagine JS
dynamically sourcing text cues.

>
>> 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 15:32:13 UTC