Add note about deviceId and groupId inconsistency with other capabilities.

[jan-ivar]

Fixes #941.

---

Preview | Diff

[eladalon1983]

Could you please help me figure out a hypothetical Web app that'd benefit of this change?

[jan-ivar]

It would simplify any app that throws up a user interface to modify constraints. But the overall benefit here is to simplify the logic. The fact that few actual apps rely on it actually helps with that.

[alvestrand]

We have used sequence to indicate a bounded set of possible values, I'm not sure if this syntax was chosen to indicate an unknowable set of values.

From the constrainable pattern text:

"Capabilities is a dictionary containing one or more key-value pairs, where each key MUST be a constrainable property, and each value MUST be a subset of the set of values allowed for that property. "

Query: should there be a recommendation that the value given is the default device for that type, and that more values should only be added if they would be returned in navigator.mediaDevices? Or is that making life more complicated?

[jan-ivar]

The history here is that settings, capabilities, and constraints originally all used the same single WebIDL dictionary, MediaTrackConstraintSet. This made sense from a spec economy pov, since you can express both settings and capabilities as constraints. I.e. settings and capabilities are subsets of constraints (and also valid arguments to constraints, even today).

But then we realized this was a parsing nightmare for JS, since no guarantees were given in prose about how a value would be returned, e.g. in getCapabilities().

JS would in theory have to be ready for a user agent to return e.g. {channelCount: 1 or {channelCount: [1]} or {channelCount: {exact:1} or {channelCount: {exact: [1]}. And that this was terrible for web compat.

It was when making this transition to tripple dictionaries that this editorial mistake was introduced IMHO.

[jan-ivar]

Folks prefer an oops note instead.