W3C home > Mailing lists > Public > public-html@w3.org > April 2013

Re: TextTrack API changes

From: Bob Lund <B.Lund@CableLabs.com>
Date: Mon, 29 Apr 2013 15:30:45 +0000
To: Simon Pieters <simonp@opera.com>, Glenn Adams <glenn@skynav.com>
CC: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Pierre-Anthony Lemieux <pal@sandflow.com>, "Jerry Smith (WINDOWS)" <jdsmith@microsoft.com>, "Mark Vickers @ Comcast" <mark_vickers@cable.comcast.com>, public-html <public-html@w3.org>
Message-ID: <CDA3EDEC.2B835%b.lund@cablelabs.com>

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
>construct cues, then a JS-exposed constructor is not necessary.
>>> From what I can tell, a constructor was exposed only to provide a
>>> to
>> programmatically construct a text track via JS,
>> 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.
>> 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
>>> 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
>> to define such a mapping, and a very early straw man draft was
>> 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
>>> 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
>> I
>> point out above that many (most) cue instances will be constructed
>> internally using not necessarily exposed constructors, i.e., a cue
>> 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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:32 UTC