Element.prototype.{outer,inner}HTML are non-standard, yet exposed by web-sys

[ghost]

From https://rustwasm.github.io/docs/wasm-bindgen/examples/dom.html:

Using web-sys we're able to interact with all the standard web platform methods, including those of the DOM!

The only problem with this sentence is that it is immediately contradicted by showing an example that uses set_inner_html, which I presume corrosponds to the Element#innerHTML setter, if so, then it has showed a browser extension that isn't a part of the W3C DOM API.

Is wasm-bindgen intentionally supporting non-standard parts of the DOM too?
Would there be a cost to removing the bindings to anything non-standard?

innerHTML and outerHTML are defined in a working draft started last year: https://w3c.github.io/DOM-Parsing
I believe that this is equivalent to implementing an API in js-sys before it hits stage 4.

---

Then there are things like escape, and unescape, which the ECMAScript spec makes no guarantees whatsoever about their existence.

Their section in the spec starts off with the following:

Programmers should not use or assume the existence of these features and behaviors when writing new ECMAScript code

[alexcrichton]

This is not necessarily intended, it's just an artifact of us bulk-importing WebIDL without a ton of review. As cases like this pop up if things are broken we try to fix things.

[ghost]

For things that slip though, what is your normal course of action?

Should I create a PR to remove it, and update the example in the documentation?

[alexcrichton]

If it's a problem we remove it, if the API changed we update it and mark it unstable, otherwise this kind of issue is the first of its kind.

[ghost]

I see, would you be fine with a PR updating the docs to use a standardized API at least?

[alexcrichton]

Sure! If it doesn't actually break anything or much in practice I would be fine removing these, but I'm not sure how to gauge that myself.

[ghost]

I'll open up a PR right now, I'm not sure if you can remove the API, but at least the documentation wouldn't show off a non-standard API.

[ghost]

Maybe the draft APIs ought to be marked unstable and the Annex B ECMAScript APIs marked as deprecated, respectively? If it could be done on a major update as a breaking change, that could work.

Otherwise, if the change isn't worthwhile, I'd like to close the issue relatively soon, to clear my issue queue.

[alexcrichton]

Personally I don't have the energy to shepherd a major release of web-sys, so until that energy comes in the form of inspiration to me or as another person, I think we're stuck with what's there today.