W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: CSP 1.1 DOM design

From: Brendan Eich <brendan@mozilla.org>
Date: Mon, 05 Nov 2012 11:01:17 -0800
Message-ID: <50980CFD.3060107@mozilla.org>
To: David Bruant <bruant.d@gmail.com>
CC: Alex Russell <slightlyoff@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-web-security@w3.org, Webapps WG <public-webapps@w3.org>, Erik Arvidsson <arv@chromium.org>, John Messerly <jmesserly@google.com>, Jacob Richman <jacobr@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
David Bruant wrote:
>> This M.O. is exacerbated by the reality that most of the folks 
>> writing these specs are C++ hackers, not JS developers. For many, 
>> WebIDL becomes a safety blanket that keeps them from having to ever 
>> think about the operational JS semantics or be confronted with the 
>> mismatches.
> Interesting. I wasn't aware of that.
> Any idea as to how to improve the state of things? It seems to be much 
> more a human problem than a WebIDL problem. Even if WebIDL improves, 
> people will likely still do the copy/paste dance, no?

What Alex describes is inherent in having any IDL language between 
native implementations and JS clients. Going through the exercise Alex 
advocated earlier for testing API completeness, of implementing using JS 
instead of C++, is one way to try to overcome this problem. Boris and 
probably others have experience here, since Proxies in ES6 allow 
implementation where JS without Proxies was insufficient.

We could get rid of WebIDL and specify interfaces only in JS, but 
without enough declarative forms that is too abstraction-leak-prone and 
high-overhead. Beating on WebIDL with the JS stick seems like the way to go.

/be

P.S.: Kudos to Alex, Arv, et al. for fighting the good fight!
Received on Monday, 5 November 2012 19:01:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT