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

Re: TextTrackCue discussions

From: Glenn Adams <glenn@skynav.com>
Date: Fri, 20 Sep 2013 11:40:48 -0600
Message-ID: <CACQ=j+eZLrpdBw85PpvaKx=K4Hjyp=Q4yUDCfr-9fYKahDLHwg@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Philip J├Ągenstedt <philipj@opera.com>, Brendan Long <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, Eric Carlson <eric.carlson@apple.com>
On Fri, Sep 20, 2013 at 2:10 AM, Simon Pieters <simonp@opera.com> wrote:

> On Fri, 20 Sep 2013 09:32:41 +0200, Glenn Adams <glenn@skynav.com> wrote:
>
>  But cue instanceof RawCue && ! cue instanceof TTMLCue would work.
>>
>
> The argument was that if authors expect `cue instanceof RawCue` to mean
> that the UA doesn't render it, we shouldn't break that expectation. It
> doesn't matter that there are other ways to check it. For instance, you
> could do cue.__proto__ == RawCue.prototype.
>

Backward compatibility with current usage doesn't seem to be a strong
consideration here given other changes being made, e.g., removing
TextTrackCue constructor.


>
> That said, your code doesn't actually work, for two reasons. (1) the `!`
> negates `cue`, not `cue instanceof TTMLCue`.


Right, wrap in parens, but you got the idea.


> (2) The UA might support other formats than TTMLCue that inherit from
> RawCue if TTMLCue sets such a precedent.


Right. In any case, using cue type to imply UA renderability or rendering
behavior is probably a poor design for exposing those behaviors.
Received on Friday, 20 September 2013 17:41:36 UTC

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