Spec-inherent capabilities of one differ from other capabilities of one, an unnecessary variant

[jan-ivar]

I'm raising this as promised in #915 (comment):

... consider how constraints with only one valid value would look. This comes up both for non-inherent constraints like channelCount on a mono mic ([1]), as well as inherent ones like deviceId.

Having the latter be "mydeviceIdString1234" rather than ["mydeviceIdString1234"] was an editor's mistake IMHO, but I never complained about it (I'm regretting that right now).

I'd support changing it (back) to a sequence of one. ... But this would need to be raised in mediacapture-main.

If we look at MediaTrackCapabilities today, we see that every member is a range, except for deviceId and groupId:

If we dig into why, it's from the commit 059a921, which (outside the scope of its title) removes ranges from facingMode, echoCancellation, deviceId, and groupId (echoCancellation and facingMode were later restored in d5820e2 & #286).

I suppose an argument for this anomaly would be that unlike the others, deviceId and groupId can never have more than one value, and that therefore it doesn't need to be represented as an array. But this breaks the Constrainable Pattern.

To the extent that pattern makes any sense at all, we should at least follow it. applyConstraints with its own exact deviceId succeeds in all browsers.

[jan-ivar]

Marking this editorial since the conclusion was to add a note about not repeating this design mistake.