Re: CSP 1.1 DOM design

On 11/5/12 5:32 AM, Alex Russell wrote:
> Other binding languages don't matter, but OK.

They can if you care about your DOM implementation being usable with 
more than one JS implementation...

> Read-only when vended from document.securityPolicy, right?

That's a good question.

If you want to allow writing to these things sometimes but not others 
while making it look like normal ES semantics, things are a bit 
complicated because of strict mode.  Your best bet is to actually use 
separate interfaces for the readonly and writable versions at that 
point, unless WebIDL is somehow changed to allow this.

>     Another thing to think about is whether reportURIs should really be
>     an IDL array (which does NOT produce a JS array on the JS side, so
>     it really depends on the expected use cases).
> I'll advocate for a JS array wherever we surface an array-like
> collection.

So WebIDL has a concept of pass-by-value which will return a JS array 
(as in, create a new array and return it).

There is no way to return a JS array that points directly into the 
stored state of an object in WebIDL right now.  Again, because we want 
to allow implementing the DOM in a language other than JS while 
remaining sane.

> It's long past time that we stopped shitting on users with
> ad-hoc collection types. If you want it read-only, vend an ES6 proxy. We
> can figure out later how to say that in WebIDL (not that it actually
> matters, IMO).

It certainly matters to me as an implementor.  Storing random JS arrays 
in my C++ code without leaking is a huge pain.  It's an even huger pain 
for WebKit, as I understand, to the point where they have vetoed specs 
that would require them to do that sort of thing.

So I would like us to be very clear on exactly what behavior we're after 
here, as a basic prerequisite, before we start trying to figure out how 
spec it and implement it.  Because it really truly does matter if we 
want it to actually happen.


Received on Monday, 5 November 2012 14:20:17 UTC