W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2014

Re: WebIDL-compatible syntax compromise

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 02 Apr 2014 17:55:14 +0200
Message-ID: <533C32E2.6040603@alvestrand.no>
To: Jan-Ivar Bruaroey <jib@mozilla.com>, public-media-capture@w3.org
On 04/02/2014 05:44 PM, Jan-Ivar Bruaroey wrote:
> On 4/2/14 11:28 AM, Harald Alvestrand wrote:
>> As I understand the proposal, one would use "advanced" constraints only
>> when one wanted to give further guidance to the browser after the
>> required and non-required constraints had been applied
>
> The application order is: required first, then advanced, then
> non-required. This gives the most deterministic behavior.

Aha.

"Non-required constraints are to be considered individually and order
must not matter" was the part I was missing. This indeed is a different
semantic than what I was reading into it.

Thanks for clarifying!


>
> I see non-required and advanced as two ways to express optional
> constraints, the main difference being that one is ordered and more
> expressive.
>
> So in my mind, someone would switch to advanced when they want more
> control and more expressive power (i.e. advanced users).
>
> The mixing of ordered and non-ordered seems esoteric, since having
> both necessitates an order (no pun intended).
>
> .: Jan-Ivar :.
>
>>   - so it would be
>> natural for the last example to have more than just "advanced" - the
>> typical "I must have a size in this range but would really prefer that
>> size" example could be expressed as
>>
>> constraints = {
>>     required: "width",
>>     width: {min: 230, max: 1024},
>>     advanced: [{width: 640}]
>> }
>>
>> BTW: I don't like the name "advanced" (what do we do if we need
>> something even more complex) - perhaps we could call it "refinements"?
>>
>> constraints = {
>>     width: {min: 230, max: 1024},
>>     refinements: [{width: 640}]
>> }
>>
>>
>>
>
>


-- 
Surveillance is pervasive. Go Dark.
Received on Wednesday, 2 April 2014 15:55:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:25 UTC