Instances of HTMLElement does not expose the remove() function

[wedneyyuri]

Instances of HTMLElement don't have access to remove function.

I'm getting the following error:

Property 'remove' does not exist on type 'HTMLElement'.

Example:

var element = document.getElementById('myid');

(<HTMLElement>element).remove();

Interface ChildNode Reference

[NoInterfaceObject,
Exposed=Window]
interface ChildNode {
[Unscopeable] void before((Node or DOMString)... nodes);
[Unscopeable] void after((Node or DOMString)... nodes);
[Unscopeable] void replaceWith((Node or DOMString)... nodes);
[Unscopeable] void remove();
};
DocumentType implements ChildNode;
Element implements ChildNode;
CharacterData implements ChildNode;

[kitsonk]

I suspect this is because it is not yet part of the DOM standard and isn't yet widely supported: https://developer.mozilla.org/en-US/docs/Web/API/ChildNode/remove

[NekR]

@kitsonk I believe all non-IE is widely enough :-)

But to be serious, many people use this, especially in extensions development because extensions are not targeted to IE. I believe it's already defacto standard, no matter if it will be standardized on W3C/whatwg or not.

[RyanCavanaugh]

A method that exists in browsers used by developers but not in IE is exactly the kind of API that shouldn't be in lib.d.ts.

If you want to opt-in to this method:

interface HTMLElement {
  remove(): void;
}

[NekR]

@RyanCavanaugh

Cannot understand. So you are saying TypeScript is only for IE users or only for MS?

Each user can easily define most of DOM methods on HTMLElement (but of course .remove() not only for HTML elements), so let's then remove other methods.

This is good what you are generating dom declarations for IE, but you easily can have dom.static.d.tsand include there methods/props which IE is missing, but which are in the world and in use.

[danquirk]

@NekR You misunderstand. We want lib.d.ts to be trustworthy and correct by default. That means you should get a list of completion results and compilation errors that match the common case. We don't want tsc to happily suggest and compile a method which then results in runtime failures on a large portion of machines running that code (whether that large portion is IE users or Chrome users or others). That means we don't want vendor prefixed items, we don't want items from the standard that aren't implemented by (m)any browsers yet, or items that are in a web browsers but not in a standard, etc. If for whatever reason you do want those things, you have an easy route to add them (as Ryan showed) and you can share any such modified lib.d.ts for others too. The alternative (requiring everyone who targets a particular platform know this problem and then go through and cleanse lib.d.ts of things that won't work for them) is much more painful and impactful.

[NekR]

That means we don't want vendor prefixed items

But you have them.

we don't want items from the standard that aren't implemented by (m)any browsers yet

So let's say IE does not supports WebGL. Should you then include definition of it to you .d.ts files? I am really not getting it. There is a difference between "many" and "not IE".

or items that are in a web browsers but not in a standard, etc.

I believe it's in standard, it's not a recommendation yet, but it is there. Latest published version has it: http://www.w3.org/TR/dom/

(requiring everyone who targets a particular platform know this problem and then go through and cleanse lib.d.ts of things that won't work for them)

Again, I do not think non-IE is particular platform.

I am not asking here about Object.observe which is in 1 implementation of 4, but about thing which is in 3 of 4 implementations. I believe it's enough.

Or, one more thing. Just imagine IE will have support of .remove() but it still won't be a Recommendation (just in state as now). Will you then add it to lib.d.ts? If so, the why? Because IE has it?

[NekR]

Oh, sorry, I am wrong -- 4 of 5 implementations supports it (Opera on Presto also has it).

[mhegazy]

@NekR, IE is not of consequence here.. we just have a script from the IE folks that makes generating and updating the library file easy. manual update has is not sustainable, we tried that :)

The right thing to do is to generate the library from the dom spec at w3.org. I have filed an issue for this #3027. We would be open to taking a Pull Request for this assuming you would be interested.