Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node.parentElement should be Element | null, not HTMLElement | null #1151

Closed
trusktr opened this issue Sep 18, 2021 · 4 comments
Closed

Node.parentElement should be Element | null, not HTMLElement | null #1151

trusktr opened this issue Sep 18, 2021 · 4 comments

Comments

@trusktr
Copy link

trusktr commented Sep 18, 2021

Hello! I'm new to this. How exactly would I change that?

For example, a <g> element somewhere inside an <svg> element will have a .parentElement that is an SVGElement, which is not an HTMLElement.

@saschanaz
Copy link
Contributor

saschanaz commented Sep 19, 2021

This is true and was done by #885, but then reverted by #970. Seems there were tons of breakages. @orta

I doubt we can do this if that was the case, but it at least needs some comment about it.

@trusktr
Copy link
Author

trusktr commented Sep 19, 2021

I left some comments. Plus imagine when something useful like this comes out in the future:

WICG/webcomponents#942

The only proper type for these DOM APIs is Element.

@HolgerJeromin
Copy link
Contributor

HolgerJeromin commented Sep 20, 2021

@trusktr
Technically you are right in moving to Element. But this would break many applications. Most do only deal with HTML and would need manual adjustments.
Developers should be happy and not annoyed by forcing them to touch all DOM touching code with compiled for years.
SVG users are right now forced to type assert anyway.

ref microsoft/TypeScript#42067 (comment)
microsoft/TypeScript#4689 (comment)

@orta
Copy link
Contributor

orta commented Sep 27, 2021

Yeah, this has been well covered and discussed. I don't think I've seen anything new in the comments to warrant keeping this issue around. If you'd like you, can fork this repo to ship your own dom.d.ts build with this in 4.5, but it's unlikely to come in by default given the trade-offs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants