document.getElementById is not correctly typed

[Judekeyser]

🔎 Search Terms

getElementById

🕗 Version & Regression Information

TypeScript 5.7.2

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABAUwBQA8BciDOUBOMYA5gJTYASAKgLIAyAogDbIC2yYUiAPomCEyaIA3onzIoIfEgAmcCCHacAdMQnM2HKACEAngEkZGUgG5EAXyA

💻 Code

No response

🙁 Actual behavior

The getElementById interface looks wrongly typed, as TypeScript ensures it would return a HTMLElement (see for example https://www.typescriptlang.org/docs/handbook/dom-manipulation.html#documentgetelementbyid)

However, MDN and the specification claims this method would return a generic Element , in particular it could return a SVGElement or any other kind of element (see: https://developer.mozilla.org/en-US/docs/Web/API/Document/getElementById). A quick trial in a browser obviously confirms such case is legit.

🙂 Expected behavior

The return type of getElementById should be Element | null

EDIT Apparently the issue is known since at leats 2020. Fair enough. Is it possible to have a documentation that mentions this limitation and others? It would help others so much.

Additional information about the issue

No response

[MartinJohns]

This is intentional. See: microsoft/TypeScript-DOM-lib-generator#1151 (comment)

[Judekeyser]

Good to know... thank you

There is no plan to announce a clean-up of the API in the forthcoming 3 years (say -- since the link you mention is already 3 years old) and just give users time to migrate their code base ?

Is it maybe possible to mention that limitation in the doc or something, so that other people dont have to dig github issues (which is not really direct to dig in this issue: I couldnt find any of the links mentioned above) ?

[ehoogeveen-medweb]

Might be worth filing at https://github.com/uhyo/better-typescript-lib as it seems like the sort of change they would take.

[Judekeyser]

Done: uhyo/better-typescript-lib#63

Is it in the realm of possibilities, to update the TypeScript documentation with a note that indicates the wrong typing is an acknowledged limitation ?

Reasoning is that the issue reappears periodically since at least 2020. If a note was left in the documentation, maybe people would stop opening ticket for it...