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

Re: TextTrack API changes

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 30 Apr 2013 10:05:58 +1000
Message-ID: <CAHp8n2mpL_mr=1dPVpA7Oj81W3-cte96XtwK6ns3bmXeiZkF9Q@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Simon Pieters <simonp@opera.com>, Pierre-Anthony Lemieux <pal@sandflow.com>, Bob Lund <B.Lund@cablelabs.com>, "Jerry Smith (WINDOWS)" <jdsmith@microsoft.com>, "Mark Vickers @ Comcast" <mark_vickers@cable.comcast.com>, public-html <public-html@w3.org>
On Tue, Apr 30, 2013 at 2:15 AM, Glenn Adams <glenn@skynav.com> wrote:

> On Mon, Apr 29, 2013 at 1:42 AM, Simon Pieters <simonp@opera.com> wrote:
>> On Mon, 29 Apr 2013 10:25:35 +0200, Glenn Adams <glenn@skynav.com> wrote:
>>  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.
> What I mean is that using this suggested approach depends on having a type
> specific interface object (TTMLCue in this example). However, as I
> previously cited, it isn't (or shouldn't be) necessary to define a type
> specific cue interface, particularly if TextTrackCue as defined can serve
> as a concrete instance class and cue construction is performed internally
> in the UA.

Right. That's what the new TextTrackCue API does. It doesn't need a
constructor when the browser creates the cue list, which is why it doesn't
have a constructor. But when we need JS to parse a cue format, we need a
format-specific parsing algorithm attached to it and we need a constructor.
Thus, the inheritance.

Received on Tuesday, 30 April 2013 00:06:45 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:02 UTC