Remove ShadowRoot#innerHTML

[falsandtru]

Fixes microsoft/TypeScript#29820

[saschanaz]

I intentionally kept it when I did #603 because browsers out there support it and spec authors want to properly spec it.

[falsandtru]

I think undocumented proposed APIs shouldn't be added but I'm not sure they should be kept when they are already added.

[saschanaz]

@falsandtru IMO undocumented APIs can stay if they are widely implemented. Recently web folks tend to spec those widespread APIs rather than remove it from browsers.

[falsandtru]

But they may be removed.

[saschanaz]

@falsandtru True. When you are not sure, try opening an issue on the relevant web spec. Then the spec authors will discuss what should be done. If they decide to remove it, IMO that's when TSJS-lib-generator removes the API.

[falsandtru]

Just to clarify, I mean "added" means "added to declaration files of TypeScript" at #660 (comment).

[saschanaz]

I understood correctly then 😃

My opinion:

1. It's already in lib.d.ts
2. It's widely implemented
3. The spec authors agree to add it to the specification. That means even if we remove it, we'll have to add it again.

So I think it should stay.

[saschanaz]

Hi @falsandtru, the spec just added the official ShadowRoot.innerHTML definition! w3c/DOM-Parsing#42 🎉

Please run npm run fetch-idl -- "DOM Parsing and Serialization" to refresh the IDL 👍

[falsandtru]

Why you didn't update http://w3c.github.io/webcomponents/spec/shadow/?

[saschanaz]

@falsandtru Read the warning at the top of the spec, that's why I didn't 😆

innerHTML is defined in DOM Parsing and Serialization and so naturally ShadowRoot.innerHTML should go there too.

See also WICG/webcomponents#661.

[falsandtru]

I saw such extensional definition style for the first time. Confirmed that spec is used to both Element and ShadowRoot.

[saschanaz]

Would you mind opening a new PR to remove the addedTypes.json item and replace it by the official IDL?

[falsandtru]

I've no plan. Your PR wouldn't conflict.