The mandatory constraint is a footgun

I've implemented a strict interpretation of the spec's mandatory 
constraint that treats unknown keys as unsupported, I've tried it, and I 
think it is wrong.

Scripts should just work, so you mustn't use 'mandatory' unless you also 
code up a fallback, yet we've made it the thing people try first (with 
its marginally preferable syntax).

With future constraints coming, 'mandatory' is an invite to fail on a 
subset of browsers, a honeypot for newbie webdevs who test only their 
favorite browser(s).

At the same time, 'mandatory' is a sucky api for asking what the browser 
supports, because you can't just ask, you have to be prepared to do.

So it is bad for simple devs who just want to do, and bad for advanced 
devs who just want to ask.

It also goes against webidl (maybe even against the web), requiring 
implementers to circumvent dictionaries, which, as Travis points out, 
disallow detection of unknown keys for this very reason (future-proofing).

---

Now, all this may be justified, if there were no other way.

But I think there is another way:

MINIMALLY:

 1. Browsers must have a getCapabilities() query that returns which
    constraints it implements.
 2. We clarify that mandatory constraints are webidl dictionaries, e.g.
    unknown keys are ignored.
 3. Browsers must include in webidl only the keys they actually implement.


The simple dev (with no fallback) can now just do, and things work as 
well as possible. This is the best outcome for this person.

The advanced dev (with fallback) uses getCapabilites() and /then/ uses 
gUM with 'mandatory' to narrow sources only by the constraints the 
browser supports, giving them the control needed to make intelligent 
fallbacks.

This works with webidl, and is webby.

IDEALLY:

 1. I'd love to see us go further and adopt a constraint format without
    the now-confusing name 'mandatory', like my "dictionaries of
    decreasing preference" proposal
    http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0052.html


.: Jan-Ivar :.