Re: Why ignoring unknown mandatory constraints is not stupid

On 11/19/13 4:29 AM, Stefan Håkansson LK wrote:
> On 18/11/13 21:57, Harald Alvestrand wrote:
>> But I think I'll stop posting on this subject. Let's hear from others.
> Well, as you asked for it:
>
> On the topic of gUM failing or not on unknown mandatory constraints
> ===================================================================
> I come to the same conclusion as Harald. If we take the example of
> "zoom" (which seems the one just outside mandatory-to-support according
> to slide 24 in
> http://www.w3.org/wiki/images/f/fd/Constraints20130406.pdf): Assume my
> app for some reason must be able to control zoom (so it puts it as a
> mandatory constraint for gUM). If the browser doesn't understand "zoom",
> I am not helped by a success CB because the browser can't control the
> zoom - and that was a mandatory requirement for me.
>
> On getSupportedConstraints
> ==========================
> This is a really good proposal I think, we should introduce (something
> like) this.

Problem followed by remedy.

Your example uses gUM constraints to infer whether a browser supports zoom, just like Harald's did for thermal. That's exactly what getSupportedConstraints() solves. I hope you agree you should call that to learn what the browser supports and doesn't support. It is a much simpler question to answer that doesn't need to involve gUM or the risk of arousing a user permission prompt at all.

As Adam pointed out, we should not assume that every constraint will be useless without browser support. "zoomOnFaces" would presumably not require browser support.

No matter how many turn out to be of one kind or the other, asking directly is a better API anyway because now the app has better information, and we can discuss fixing things so people can use mandatory constraints for new constraints much sooner than they otherwise would without risk of blocking legitimate sources in the cases where we're not certain the app wishes shutoff in the unknown case. Let the programmer turn it off explicitly, then people can yell at the programmer.

We've seen many examples of invariants, and not so many on false negatives, so let me offer one:

Our gUM constraint skeleton is riding the Firefox Aurora train right now, but with almost no constraints implemented (facingMode being the lone one). Pause and think about that.

As a result, anyone using mandatory for ANYTHING is going to be extremely sad, because their app will stop working on Firefox. We know the group of programmers affected is not zero, because we are already hearing from them: https://bugzilla.mozilla.org/show_bug.cgi?id=927358

Sure you can pick at this example, and say the programmer thought these were MTI, but A) that hasn't been clear until extremely recently, and B) I might equally argue these programmers thought they could describe their needs in relation to cameras, without having to consider that the old-browser case would produce complaints from valid users.

Even if you disagree about blame in this example, you cannot refute that this is exactly how it will go down in the future when something works in one browser and not another.

When I program something in JS, here's how I, nay I claim everyone, thinks:

   Does it work in Firefox or Chrome? Yes = Blame that browser, not my app.

I agree that ensuring a nice UX is great if you can avoid breaking people.

> Would it make sense to go with only optional constraints for the first
> version?

See, now how is that preferable to what I'm proposing?

.: Jan-Ivar :.

Received on Tuesday, 19 November 2013 15:56:28 UTC