W3C home > Mailing lists > Public > public-media-capture@w3.org > November 2013

Re: The mandatory constraint is a footgun

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 14 Nov 2013 20:10:56 +0800
Message-ID: <CAHp8n2=iuSr9ZKRd+i9A0u5g00uD4SaTzrNgVkLMDHNeS_offQ@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On Tue, Nov 12, 2013 at 2:04 PM, Jan-Ivar Bruaroey <jib@mozilla.com> 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:
> Browsers must have a getCapabilities() query that returns which constraints
> it implements.
> We clarify that mandatory constraints are webidl dictionaries, e.g. unknown
> keys are ignored.
> Browsers must include in webidl only the keys they actually implement.

I don't see that as an improvement. If you fall through all the listed
constraints, you still fail to get the media (and end up in an
"overconstrained" exception). That's no different to having mandatory
constraints. In fact, it's worse, because you can't say that you
either want it to fail when the constraints are not met or you want it
to just do its best (which is what "optional" allows for today).

However, I do think there are 2 things that should be improved upon:

1. the naming of "optional". Since it's optional, it indicates to the
JS dev that the browser will ignore it. I'd prefer that to be called

2. I need to be able to tell the browser to do its best in one or more
dimensions: "give me the highest/lowest possible resolution". There is
no way to specify that right now. Travis registered a bug for that
today: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23820


> 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.
> 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 Thursday, 14 November 2013 12:11:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:43 UTC