- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 1 Aug 2014 05:24:49 +0000
- To: Peter Thatcher <pthatcher@google.com>, Martin Thomson <martin.thomson@gmail.com>
- CC: Jan-Ivar Bruaroey <jib@mozilla.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
On 01/08/14 03:32, Peter Thatcher wrote: > At the interim in DC, the reaction from the crowd was strongly against > making bare values mean required/exact. I think you'll have a hard > time convincing everyone. 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). I think I've said that before: I'm all for it. All energy we spend discussing how to interpret a bare value is to me a clear indication of that we should not allow them. My 5 cents. > It sure would make the WebIDL a lot more simple :). > > On Thu, Jul 31, 2014 at 5:29 PM, Martin Thomson > <martin.thomson@gmail.com> wrote: >> On 31 July 2014 17:13, Jan-Ivar Bruaroey <jib@mozilla.com> wrote: >>> A plain value literally is mutually exclusive with {}, almost exactly like >>> specifying a value is mutually exclusive with providing ranges and/or hints >>> for that value. To me it reads as "just this value please", yet users may >>> get cameras that are not 1280 wide or 1.78 aspect here, even though these >>> values are specified in the top "required" section. >> >> The top section is not "required". And "please" is the perfect way to >> phrase a request (as opposed to a demand). >> >>> Add to this that plain values in the advanced array are not ideal, and it's >>> a semantic mess. >> >> I think that bare values could equal anything and we get the same. >> >> Besides, anything in the advanced array is closer to ideal than a hard >> requirement, since if the set of values can't be achieved, it moves on >> to the next option. >> >>> Is it truly too late to rectify this? >> >> It's never too late to fix actual problems. We just have to agree >> that there is an actual problem. I don't see an actual problem here. >> > >
Received on Friday, 1 August 2014 05:25:16 UTC