'innerText' should not be nullable in most of Node's derived types

[DanielRosenwasser]

Compile the following with --strictNullChecks with the DOM available.

const foo = document.createElement("div");
const s: string = foo.textContent;

Expected: No error
Actual: Type 'string | null' is not assignable to type 'string'.

From https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent:

• textContent returns null if the element is a document, a document type, or a notation. [...]
• If the node is a CDATA section, a comment, a processing instruction, or a text node, textContent returns the text inside this node (the nodeValue).
• For other node types, textContent returns the concatenation of the textContent attribute value of every child node, excluding comments and processing instruction nodes. This is an empty string if the node has no children.

Proposed fix: textContent will be defined as nullable inNode, but overridden asstring` in most of its descendants.

[mhegazy]

PRs welcomed. You can find more information about contributing lib.d.ts fixes at https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing-libdts-fixes.

[FranklinWhale]

Unfortunately null is always allowed when textContent is set:

https://dom.spec.whatwg.org/#dom-node-textcontent

I have tried to use getter and setter to fix this, but that seems not possible because "'get' and 'set' accessor must have the same type".

get textContent(): string;
set textContent(value: string | null);

[zanona]

Another test case:

const span : HTMElement | null = document.body.querySelector('span');
let value: string = '';
if (span instanceof HTMLElement) {
   value = span.textContent; // Type 'string | null' is not assignable to type 'string'. 
}

Expected:

Valid, since anything subclass of Element type should always return a string.

[ExE-Boss]

@FranklinWhale That depends on #32821/#2521.

[lionel-rowe]

Can't TypeScript just be a little stricter than the spec here, and disallow setting textContent to null on nodes where its value is always a string? I can't fathom why you'd ever even want to do that (as opposed to setting it to "", which has functionally identical behavior)

[Jamesernator]

Can't TypeScript just be a little stricter than the spec here, and disallow setting textContent to null on nodes where its value is always a string?

It doesn't even need to, as far as I can tell the needed behaviour here has worked since TS4.3.

[Andarist]

This would be quite a nice improvement. The DOM types are heavily generated and it's not straightforward to tinker with them. Perhaps @saschanaz could advise how this could be achieved in practice there? I could give it a shot then.