getElementById inconsistent between TS and Closure

[evmar]

document.getElementById returns an Element in Closure and an HTMLElement in TS. (Element is the supertype; SVG elements are a sibling to HTML elements.) This leads to compilation problems like:

WARNING - initializing variable
found   : (Element|null)
required: (HTMLElement|null)
    let /** @type {HTMLElement} */ outputEl = document.getElementById('output');

microsoft/TypeScript#3263 (comment) says: "However, in the case of getElementById, we made it convenient by returning HTMLElement by default, although it is different from the spec." Sadness.

It looks like they might change something in this area in microsoft/TypeScript#4689 .

See also #42 . This is maybe an argument for using our own modified standard library.

[evmar]

To repro this in a test:

let foo = document.getElementById('foo');

it produces

let /** @type {HTMLElement} */ foo = document.getElementById('foo');

[evmar]

Note that you can't work around this with coercions because of bugs like microsoft/TypeScript#6982 where comments are dropped.

let foo = <Element>document.getElementById('foo');

becomes

let /** @type {Element} */ foo = /** @type {Element} */(( <Element>document.getElementById('foo')));

becomes

let /** @type {Element} */ foo = (document.getElementById('foo'));

And see that "Element" was dropped.

[mprobst]

Shouldn't we initially disable type checking within the TypeScript file? It's nice to have checking for code depending on it, but we don't need the check in the file – TS has already type checked that, right?

[evmar]

In theory we're relying on types for optimization, so I'm not sure what it means if we disable type checking. Like if you write

let foo = document.getElementById('foo');
foo.barField;

where "barField" is in HTMLElement but not Element, I'm not sure what the Closure optimizer will do to barField when it thinks it's not a valid field.

[mprobst]

My unchecked understanding is that Closure Compiler will rename properties
that are never mentioned in externs, but at least without --disambiguate
options will just never rename a property that's mentioned anywhere in
your externs.

With it on, it's unclear, there's some stuff in Closure Compiler where it's
trying to be conservative if a sub or supertype defines a property.

[evmar]

We suppressed checkTypes.