- 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