The UNKNOWN mandatory constraint behavior is a footgun

I realize I shot my message in the foot by not being more precise in my 
subject line earlier.

It is the dictated treatment of mandatory constraints *unknown to the 
UA* that I'm highlighting a problem with.

I 100% support the existing spec behavior of mandatory constraints for 
constraints that the browser implements, and I would hate to see us make 
them harder to use. If an app doesn't want to support a resolution, lets 
not make it harder for it to declare this.

I also don't think browsers should police constraints, taking control 
away from webapps over which ones can be declared as mandatory. Power to 
the webapp!

In other words, webapps should be free to discriminate, without having 
to deal with the "bug" that browsers blind to a new constraint type will 
fail 100% of the time, rather than grant access to the best available 
device based on the information it does understand (which may just work, 
either directly or with the user's help).

I urge you to re-read my suggestion below if this wasn't clear the first 
time.

Sorry for any confusion this caused,

.: Jan-Ivar :.

On 11/12/13 1:04 AM, Jan-Ivar Bruaroey wrote:
> 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 :.
>


-- 
.: Jan-Ivar :.