Re: Possible Constraint Syntax Compromise

I agree with Dan's explanation of WebIDL bindings and Peter's assessment 
of our choices at this juncture. I'll add that this API gives JS 
developers additional information (browser capabilities with virtually 
no fingerprinting issues) and gives it earlier (before gUM), making for 
better choices and a more desirable syntax (the latest sticking point).

+1

.: Jan-Ivar :.

On 5/21/14 6:50 AM, Dan Burnett wrote:
> Jan-Ivar might want to comment here, as he has often explained that Firefox does its parsing based on WebIDL and that an unknown constraint disappears during that process.  As our standard list of constrainable properties becomes more and more supported the need to check in advance for such unknown constraints should also diminish, unless of course the developer is specifically using a non-standard (e.g., experimental) constraint.
>
> -- dan
>
> On May 20, 2014, at 9:16 PM, Timothy B. Terriberry wrote:
>
>> Peter Thatcher wrote:
>>> Out of those three, all the people I talked to preferred #3, which is
>>> why I have proposed it.  If there is something we are all missing about
>>> WebIDL that gives an easier exit from this conundrum, that would be
>>> welcome news.
>> No, it does not surprise me this is not expressible in WebIDL, so I guess it will not throw an exception. But we're still required by contract to call either the success or error callback, and what it sounded like you were saying was that the browser was free to ignore the constraint completely and return success.
>>
>


-- 
.: Jan-Ivar :.

Received on Wednesday, 21 May 2014 14:51:13 UTC