Re: The mandatory constraint is a footgun

On 12/11/13 07:05, 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.

Do you include the values as well (I mean: it is likely that width and 
height will be supported, but do you include their respective min and 
max values)?

I ask, because one argument against getCapabilities in the past has been 
around fingerprinting. You can get info without the user at all getting 
to know about it. That is not a problem when using optional constraints 
with gUM (because the user would be presented with the consent prompt). 
It is a little problematic with mandatory constraints with gUM because 
the app could repeat gUM with lower and lower reqs, but eventually the 
user would get informed (because the constraints can be met).

>  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 :.
>

Received on Wednesday, 13 November 2013 01:09:54 UTC