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

`.supports()` relies on users calling it, outsourcing the real API problem rather than solving it IMHO.

That's my mea culpa 2 years after having implemented [getSupportedConstraints](https://w3c.github.io/mediacapture-main/#dom-mediadevices-getsupportedconstraints):

What we wanted was this to fail on older browsers that didn't know about e.g. [`torch`](https://w3c.github.io/mediacapture-image/#torch):
```js
track.applyConstraints({torch: {exact: true}}); // OverconstrainedError: what's torch?
```
What we got was:
```js
if (!navigator.mediaDevices.getSupportedConstraints().torch) {
  throw new DOMException("what's torch?", "OverconstrainedError");
}
track.applyConstraints({torch: {exact: true}});
```
It's a terrible API: People forget it, ignore it, or don't know about it, because their browser works.

It's also inherently unnecessary, except to work around WebIDL.

In hindsight, we could have specified `object` instead of a `MediaTrackConstraintSet` dictionary, with prose to copy it into a new `MediaTrackConstraintSet`, and throw `TypeError` on leftovers.¹

I don't see why binding code couldn't do that for us. E.g.:
```js
[ThrowOnUnknownMembers]
dictionary RequiredMediaTrackConstraints : MediaTrackConstraints {};
```

<sub>1) I'm simplifying. Constraints also defines `ideal` which unlike `exact` should be ignored, so `getSupportedConstraints` is a lost cause.</sub>

-- 
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-304334556