[heycam/webidl] Making methods more future-proof (#954)

I've recently seen a couple of code examples that could create compatibility issues later:

```js
const nextFrame = new Promise(requestAnimationFrame);
```

The above works because `requestAnimationFrame` only takes one arg. If we change it to take two, the above may behave differently and unexpectedly.

```js
const controller = new AbortController();
el.addEventListener(name, callback, controller);
```

The above works because [`AbortController`](https://dom.spec.whatwg.org/#abortcontroller) and [`AddEventListenerOptions`](https://dom.spec.whatwg.org/#dictdef-addeventlisteneroptions) share a `signal` property with the same intent. If we change either of these in a way that creates a cross-over that doesn't have the same intent, the above may behave differently and unexpectedly.

Our current strategy is to make changes to the platform, and be forced into different pattern if it creates a compatibility issue due to patterns like above. Should we do something more preemptive?

We could throw in cases where functions are called with more arguments than expected, and throw if option objects have unexpected properties (aside from the properties that already come with `Object`).

This would likely be breaking if applied to existing APIs, so it should only be applied to new APIs. Existing APIs could show a console warning instead.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/954