Re: Bug 23935 - Proposal: New syntax for constraints

On 4 Dec 2013 08:47, "Jan-Ivar Bruaroey" <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]
>> Sent: Tuesday, December 03, 2013 3:47 PM
>> To: Jim Barnett; 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 :.
>
>