Re: [heycam/webidl] Need pattern for feature detecting dictionary members (#107)

I had an "exotic idea" come into my mind about this issue, I hope that after 5 years it's ok to propose such ideas, at least to make things move a bit.
Note that I am really not proficient in WebIDL and thus not entirely sure of what can and can't be done, so this proposal may very well be completely unfeasible, if so, sorry in advance.  
Also, this assumes ES binding, which might once again be a completely wrong assumption.

Anyway, the idea would be to expose a new global method (name can totally change, I'm really bad at naming)

```webidl
interface mixin WindowOrWorkerGlobalScope { // or any global context really
+  boolean methodSupports(Function method, any... arguments);
}
```

Where web authors would pass directly the ECMAScript *function object* they have access to as the first argument and the arguments they'd like to test as the following arguments.  
Each argument would be tested against the UA's IDL implementation to see if it is recognized as potentially valid.

For instance to test for Worker's `type = "module"` support, one would write
```js
globalThis.methodSupports(Worker, "" /* the URL param */, { type: "module" } /* the option param */) 
```

To avoid creating void objects only to pass the required arguments, maybe `undefined` or `null` values should be ignored from the tests, e.g
```js
globalThis.methodSupports(EventTarget.prototype.addEventListener, null, null, { signal } );
```
would ignore both the event type and callback params but check if `signal` is an AbortSignal.

If the arguments length is bigger than the one expected, or if a dictionary member is not recognized, or if the value of an enum is not valid, the method should return `false`, otherwise it should return `true` (so it doesn't look if required options are passed or not, it only checks that the passed ones are recognized).

I believe such a model would solve the issues outlined with the two proposed solutions so far:

- No need to expose every dictionary, nor to fix their names nor even to reify them in any other way than what is currently done.
- Can be automatically added to any method, no need to subscribe at definition (though some definitions may want their own validation steps?)
- Obviously works for many methods defined on the same interface
- Works for both enums and dictionary options

However it also comes with its own questions (and many others I probably didn't see myself)

 - Can WebIDL link ECMAScript function objects to the actual IDL method? Even if there isn't any mechanism today, could one be built?
 - What about all the methods that are language specific and not linked to IDL? e.g should this method also work for ES `Intl.numberFormats` and `Array.from` and everything else? I doubt many web authors are interested in where a method has been specced from, they will probably not understand why some methods are excluded.
 - How should DOMStrings be tested? Many methods will actually fail on invalid values, for instance the `HTMLCanvasElement.getContext()` method uses a DOMString instead of an enum and returns `null` when the value provided isn't recognized, should `methodSupports(canvas.getContext, "webgpu")` return `true` even in UAs that don't support  this context type?
 - Is the difference constructor vs method calls gonna be a problem?

-- 
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/107#issuecomment-917324639