- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Mon, 04 Aug 2014 16:23:01 -0400
- To: Peter Thatcher <pthatcher@google.com>, Martin Thomson <martin.thomson@gmail.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 7/31/14 9:30 PM, Peter Thatcher wrote: > At the interim in DC, the reaction from the crowd was strongly against > making bare values mean required/exact. I recall more apathy than discontent, and I recall no actual arguments raised. The minutes don't show anything either http://www.w3.org/2014/05/21-mediacap-minutes.html - Maybe the recording reveals something. In any case, can someone humor me and articulate a reason? > I think you'll have a hard time convincing everyone. I'm not sure everyone is aware. For instance, Example 1 in the spec is not clear that the call may succeed with none of the specified constraints satisfied. Instead, the way it's worded actually sounds reasonable - dev.w3.org/2011/webrtc/editor/getusermedia.html#constrainable-interface > I would be interested to know, though, if > anyone would want to just remove bare values and make JS always > specify if it's suppose to be "please" (ideal) or "require" (exact). It would be a shame since, in my mind, it's syntactically clear what it should mean, we just seem afraid of its meaning. Plus it still sticks us with the "exact" keyword we never needed. To illustrate: you'll never see "exact" used in combination with any of the other constraint-modifiers, because it is semantically mutually exclusive: foo: { min: 3, max: 5, ideal: 4, exact: x } // never makes sense Exact is a loner member. The only one. So the obvious syntax to describe it would also be mutually exclusive: foo: x, because x is both semantically and syntactically mutually exclusive with the other constraint-modifiers. Ideal, in contrast, is very useful in combination with min and max. So syntactically at least, plain=exact seems like a slam dunk, since it removes the need for fluff syntax and aligns with simpler rules. The only argument I've heard against this is usability-fears: that we're concerned about people who don't read the spec and who don't notice that things may fail if they don't get what they asked for. I understand that argument, I just think it's more important that the syntax be more straight forward and intuitive than it is. - I'd also like to point out that we had mandatory/optional for a long time and this didn't seem to be a problem, even though mandatory seemed to be the go-to from the sampling of code I looked. So I find this new-found fear a bit odd. Finally, we're just discussing defaults here effectively, not adding or removing any functionality. You can always use aspectRatio: { ideal: 16/9 }, if an unconstrained preference is truly what you seek. .: Jan-Ivar :.
Received on Monday, 4 August 2014 20:23:29 UTC