Re: TextTrackCue discussions

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).