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 14:05:08 -0600
Message-ID: <CACQ=j+cBZt816JNCvVMWSQ5eQM75TPobDKKRKd7tSaZ7VTC=Vw@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 1:58 PM, Simon Pieters <simonp@opera.com> wrote:

> On Fri, 20 Sep 2013 19:40:48 +0200, Glenn Adams <glenn@skynav.com> wrote:
>  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.
> Right, but we're discussing expectations, not back compat.
> Case study: HTMLUnknownElement is used for HTML elements that the UA
> doesn't support but still exposes in the DOM. It inherits from HTMLElement.
> Elements that the UA supports inherits from HTMLElement (or uses
> HTMLElement), they never inherit from HTMLUnknownElement.

That analogy may hold for out-of-band track MIME types unrecognized by the
UA, however, it doesn't hold for in-band tracks where the UA is at least
able to extract content, including possible decoding of bytes into UTF-16
encoding units (for representation in a DOMString) or into BASE64, but the
UA doesn't take any further action (perhaps because it doesn't support
rendering a renderable @kind).
Received on Friday, 20 September 2013 20:05:57 UTC

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