Re: CSP 1.1 DOM design

On Mon, Nov 5, 2012 at 10:56 AM, David Bruant <bruant.d@gmail.com> wrote:

>  Le 05/11/2012 11:32, Alex Russell a écrit :
>
> On Mon, Nov 5, 2012 at 1:08 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 11/4/12 3:58 PM, Alex Russell wrote:
>>
>>>      DOMString toString();
>>>
>>
>> This should probably be:
>>
>>   stringifier;
>>
>> instead (which in ES will produce a toString on the prototype, but is
>> more clear about the point, and might do different things in other binding
>> languages).
>
>
>  Other binding languages don't matter, but OK.
>
> I heard Google is working on this "Dart" thing. Unless Google redefine
> APIs for every single web browser capability, it will probably need to
> define WebIDL bindings for Dart. But what do I know...
>

You know, we should go talk to the guys who designed the Dart DOM...oh,
wait, that's me (and arv and jacobr and jmesserly)!

We did *exactly* that:

    http://www.dartlang.org/articles/improving-the-dom/

The W3C/WebIDL DOM sucks and every self-respecting language will re-define
the API, preserving the invariants and basic functionality, but aligning
the surface area, types, and calling conventions with the idioms
and intrinsics of the host language:

Python: http://docs.python.org/2/library/xml.etree.elementtree.html
Ruby: http://rubydoc.info/gems/hpricot/0.8.6/frames
Java: http://www.jdom.org/news/index.html
Dart: http://www.dartlang.org/articles/improving-the-dom/
         http://api.dartlang.org/docs/bleeding_edge/dart_html.html


> Yes, it's a lot of work, but if you're not taking care to create a great
API for one of your most frequently-used libraries, you're screwing your
language and your users. I posit that every language with enough users to
matter will do this exercise (JS has done so many times over in the form of
the ubiquitous library tax that slows so many sites).

FWIW, we can still use WebIDL as a stepping stone to fix the b0rken JS
bindings. But we need to collectively stop pretending that:


   1. We should be designing JS APIs though the lens of what WebIDL
   can/can't do
   2. That there are other language consumers of WebIDL-defined DOM APIs
   that both matter and will not go their own way when presented with
   un-idiomatic/kludgy designs.

Perhaps there's some future world in which we decide that having an IDL to
describe API invariants is a good idea (although it doesn't do that today
to any reasonable degree), but nobody I know is clamoring for that.


>   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. It's long past time that we stopped shitting on users with
> ad-hoc collection types.
>
> Arguably, ES6 symbols may give a re-birth to ad-hoc collection types by
> allowing safe (uncollidable) extension of built-ins. I think an IDL array
> is fine (as far as I can tell, the difference with a regular array is just
> a different prototype).
>

That's enough to make it toxic.