Re: Syntax of new constraint proposal

On May 19, 2014, at 3:07 AM, Silvia Pfeiffer wrote:

> On Mon, May 19, 2014 at 11:21 AM, Harald Alvestrand
> <harald@alvestrand.no> wrote:
>> On 05/19/2014 02:13 AM, Silvia Pfeiffer wrote:
>>> On Mon, May 19, 2014 at 4:31 AM, Cullen Jennings (fluffy)
>>> <fluffy@cisco.com> wrote:
>>>> On May 18, 2014, at 1:21 PM, Justin Uberti <juberti@google.com> wrote:
>>>> 
>>>>> I think 'ideal' will make this less inscrutable, e.g.
>>>>> 
>>>>> videoCfg = {
>>>>> require: ["width"],
>>>>> width: { min: 640, ideal: 1920 },
>>>>> };
>>>>> 
>>>>> which to me reads even more cleanly that the mandatory/optional syntax.
>>>>> 
>>>> yah, that is even clearer - but the require things is still confusing. What about
>>>> 
>>>> videoCfg = [
>>>>    { constrain: ”width”, min: 640, ideal: 1920 },
>>>> ];
>>> 
>>> Or to express the same semantics as the first example, maybe:
>>> videoCfg = [
>>>    { constrain: ”width”, min: 640, ideal-min: 1920, ideal-max: 2560 },
>>> ];
>>> 
>>> TBH I really quite like this. It turns the constraining around from
>>> listing the attributes, then listing the requirements, then the
>>> optional (but preferred ones) to grouping all information together by
>>> constraint feature.
>> 
>> Silvia, I have absolutely no idea what the semantics of the thing you
>> have just typed is, or how it would generalize to various combinations
>> that have been put forward as use cases.
>> Since this thread started off with "required", I have no idea how you
>> would express the difference between required stuff and non-required
>> stuff in that syntax.
> 
> I interpreted the semantics of this proposal from Cullen:
> videoCfg = {
> require: ["width"],
> width: { min: 640 },
> advanced: [
>    { width: { min: 1920 } },
>    { width: { max: 2560 } } ]
> };
> 
> to mean:
> I want width to be a min of 640, but preferably between 1920 and 2560.
> 
> Therefore my adjustment of his changed proposal to include the range
> of preference rather than a single "ideal" value.
> 
> 
>> But generally:
>> 
>> I do NOT think this is a good time for coming up with more proposals.
> 
> Take that up with Cullen, who started the thread.
> I personally wasn't aware that we had already changed the Syntax again, sorry.

Sylvia, I've been meaning to mention that the reason I occasionally suggest new values (not attributes) of maxpossible and minpossible for range properties is precisely because of your use cases that you described in China.  I have never forgotten your great example of you, as the developer, not knowing what the "best" is that the browser can give you but still wanting some way to indicate that you want "the best".

I don't advocate making any of these changes now, but it would be almost trivially easy in a next version of the standard to add custom values such as "maxpossible" and "minpossible" (I'm not wedded to these names, btw), a la

advanced: [
  {width: maxpossible},
  {aspectRatio: maxpossible}
]

which would mean that ideally I want the maximum width I can get.  Then, preferably give me the maximum possible aspectRatio, assuming that doesn't keep me from getting the maximum possible width.


Again, though, I'd rather not be tweaking at this point if it means another 3 months of arguing.


> 
> Regards,
> Silvia.
> 
>> If we need to change things again, we need to have a really good reason
>> for it.
>> "Prettier" is not a really good reason.
>> 
>> 
>>> 
>>> Silvia.
>>> 
>> 
>> 
>> --
>> Surveillance is pervasive. Go Dark.
>> 
>

Received on Monday, 19 May 2014 11:48:38 UTC