Re: Bug 23935 - Proposal: New syntax for constraints

Today you're proposing "min", "max" and "mid" constraints. What about 
tomorrow? The specification shouldn't try to expose a declarative syntax 
for every kind of use-case possible. Just give applications access to 
the information they need and let *them* make the decision.

I am all for protecting users from information leakage when that 
information actually matters, but in this case it does not. This 
information is not confidential (like medical or bank records). We can 
already fingerprint browsers with high confidence: 
https://panopticlick.eff.org/<https://panopticlick.eff.org/>

Exposing a camera's capabilities is not going to make a difference with 
respect to fingerprinting. This battle is already long lost. All you'll 
achieve is a specification that is constantly chasing business use-cases 
(adding more properties with every passing day), and protecting users 
from a problem that doesn't actually exist.

Business logic should remain in the application, not in the browser.

Gili

On 03/12/2013 5:23 PM, Silvia Pfeiffer wrote:
>
>
> On 4 Dec 2013 08:47, "Jan-Ivar Bruaroey" <jib@mozilla.com 
> <mailto:jib@mozilla.com>> wrote:
> >
> > On 12/3/13 3:53 PM, Jim Barnett wrote:
> >>
> >> Sorry, I wasn’t clear.  I was referring to the request for new 
> values ‘max’, ‘min’ and ‘mid’, where {width: max} would mean “make it 
> as wide as you can”.  “min” would ask for the minimum possible value, 
> and ‘mid’ would mean “try for something in the middle of the range”.
> >
> >
> > As with anything in life, asking for the maximum without knowing 
> what it is strikes me as a very bad idea. Would you ask the Hulk to 
> hit you as hard as he can? Amount of Advil? Your app can already 
> specify any number of absolute values or ranges of values it knows 
> about (and hopefully has been tested with) Can you give me a use-case 
> where this is not sufficient?
>
> You can only test with a limited amount of cameras. Specifying all 
> possible resolutions just to get the best possible resolution from the 
> actual camera that is attached to the computer will invariably lead to 
> not getting the best possible resolution. I don't know of a way 
> currently to tell my camera to give me it's highest or lowest 
> resolution. Do you?
>
> > If expressiveness is a problem, we should address this directly, 
> which is what I believe my syntax proposal does. I can say:
> >
> > [ { width: 4096, height: 2160 },
> >   { width: 3840, height: 2160 },
> >   { width: 2880, height: 1800 },
> >   { width: { min: 1024, max: 4096 }, height: { min: 768, max: 2160 
> }, aspect: { min: 1.6, max: 1.9 } ]
> >
> > In this example, I prefer certain resolutions I have tested with 
> (even when higher ones are available), and only if I cannot get one of 
> those exact ones will I accept a range, but no less than 1024x768. How 
> would you express that today?
>
> I don't mind this new proposal. I am still keen to have special "max" 
> and "min" values.
>
> > PS: In the above example, a clever UA could deduce that higher 
> resolutions are probably preferred in the range.
>
> I don't think UAs would be going to that extend of second-guessing the 
> apo developers intention. There needs to be a simple way to tell it to 
> give me highest or lowest resolution and frame rate.
>
> Cheers,
> Silvia.
>
> > PPS: Note how readable that was. I'll bet you intuitively understood 
> what that meant. Try that with mandatory/optional.
> >
> > .: Jan-Ivar :.
> >
> >
> >>   We haven’t  introduced these yet, but there seemed to be interest 
> in them.  I think that the semantics would have to be that anything 
> the UA chose counted as correct.  Just because the property ‘foo’ 
> defines its range to be 0-1000 doesn’t mean that  the UA can actually 
> set a value of 1000 in every case (particularly if there are other 
> interacting properties), so whatever the UA gives you has to count as 
> “as good as I could do”.
> >>
> >>
> >>
> >> -          Jim
> >>
> >>
> >>
> >> From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com 
> <mailto:jib@mozilla.com>]
> >> Sent: Tuesday, December 03, 2013 3:47 PM
> >> To: Jim Barnett; public-media-capture@w3.org 
> <mailto:public-media-capture@w3.org>
> >> Subject: Re: Bug 23935 - Proposal: New syntax for constraints
> >>
> >>
> >>
> >> On 11/27/13 10:55 AM, Jim Barnett wrote:
> >>>
> >>> I prefer the current syntax.  It is more compact and makes 
> back-off easier.  Furthermore, it makes the semantics of ‘best effort’ 
> values like min/max/mid easy to understand, at least in the case of 
> optional constraints.  Suppose we have optional constraints  “prop1 
> max, prop2 max, prop3 max”.  This would  mean:  set prop1 to the 
> largest value you can, the set prop2 to the largest value you can 
> without changing prop1, then set prop3 to the largest value you can 
> get without changing prop1 or prop2.  The ordering of the constraints 
> specifies the ordering of the optimizations.
> >>
> >>
> >> I don't understand your use of min and max (what is mid?) - Can you 
> please use actual syntax?
> >>
> >> Are you saying that { width: { max: 2880 } } must return the 
> highest value possible, up to and including 2880? If so, that doesn't 
> match my understanding. Where in the spec do you read that?
> >>
> >> My interpretation is that there is no such guarantee, and that, 
> given no lower bound, browsers can return anything from the lowest 
> possible value and up to and including 2880.
> >>
> >> .: Jan-Ivar :.
> >
> >
>