The thing we're trying to avoid here is requiring it to be possible to do:

mynode = {
           nodeType: 1,
           nodeName: "foo",
           baseURI: "...",
           ownerDocument: myDoc,
           ... <rest of Node and Element APIs> ...
         };
document.documentElement.appendChild(mynode);


Every single DOM implementation out there uses a lot of internal interfaces in order to implement the DOM. Not only that, they require the implementation of a lot of these internal interfaces to be "trusted" in that they can't perform certain actions such as modify the DOM or navigate the page.

While we could argue about if this is a silly limitation in the DOM implementations, it's unlikely to change anytime soon. Thus it needs to be documented and required by implementations.

(In reply to comment #1)
Then you need to specify the actual requirements rather than hiding them behind some broad prohibitive on using a specific implementation language.

For example for appendChild you might say that the argument Node must be an object that was created as if by called some list of specified methods that would include createElement and others. 

Or you might define a categorization of object such as "trusted DOM object" that means something over and beyond just implemented a certain interface.  You when then require that certain arguments in addition to implementing some interface must also be trusted DOM objects.

It is them up to the implementers to enforce those requirements, regardless of their implementation language of choice.

When the time comes to start implementing parts of the DOM in JavaScript (and that time is near) the current prohibition isn't going to stop implementors from doing it.

(In reply to comment #2)
> (In reply to comment #1)
> Then you need to specify the actual requirements rather than hiding them behind
> some broad prohibitive on using a specific implementation language.
> 
> For example for appendChild you might say that the argument Node must be an
> object that was created as if by called some list of specified methods that
> would include createElement and others. 

That could work but would require such language in a very large set of functions. Very likely leading to people forgetting this all over leading to confusion and possibly even inconsistencies across implementations.

> Or you might define a categorization of object such as "trusted DOM object"
> that means something over and beyond just implemented a certain interface.
> You when then require that certain arguments in addition to implementing
> some interface must also be trusted DOM objects.

That is what we've done. Or at least that's what I believe the spec is attempting to do. Anything that isn't explicitly marked "[Callback]" is required to be a "trusted DOM object".

I'm all for improving the wording though if you have suggestions (and assuming Cameron is ok with it since I'm not an editor).

(In reply to comment #3)
> I'm all for improving the wording though if you have suggestions (and assuming
> Cameron is ok with it since I'm not an editor).

Yes I am.  That was written before the use case of whole DOMs implemented in JS came up.  All of the language distinguishing "host objects" and "native objects" really needs to be rewritten using terms like "implementation objects" and "user objects" or so.

If you have an ECMAScript DOM implementation, and an author writes something like that in comment 1, should we be requiring that to fail?  I think the answer to that is yes, since we want consistent behaviour across implementations in this regard, and it would be a lot of spec and implementation effort for little benefit to require that to work, I think.

Even if the language around host objects and native objects is replaced, the current version of the spec still does not allow strict conformance by pure-JS implementations in at least these two areas:

1) Interface objects are required have typeof "object", but also required to work with the instanceof operator. 

2) Objects that implement an interface are required to have a [[Class]] that matches the interface name.  

The current ES-Harmony Proxies proposal doesn't seem likely to enable either of these things.

We have considered, and should again consider, enhancing the proxies proposal to address this. See https://mail.mozilla.org/pipermail/es-discuss/2011-May/014142.html

(In reply to comment #6)
> We have considered, and should again consider, enhancing the proxies proposal
> to address this. See
> https://mail.mozilla.org/pipermail/es-discuss/2011-May/014142.html

Even if proxies could address the [[Class]] issue, I suspect that performance constraints would prevent them from being used.  One proxy per document node seems like a high price to pay.  (If [[Class]] is to be made configurable, could it be done on Object.create instead?)

For what it's worth, we (Mozilla) have an implementation of NodeList using proxies (though with a C++ handler).  It's a good bit faster than the old "host object" implementation.

The spec now states that objects in the system are either "platform objects" or "user objects".  (Better name suggestions welcome.)  The former are objects for objects implementing Node, the latter for EventListener.  I added a slightly waffley section attempting to describe this:

http://dev.w3.org/2006/webapi/WebIDL/#idl-objects

In the ECMAScript binding, most mentions of host objects have been replaced by platform objects and native objects with user objects, where appropriate.  Hopefully this is sufficient to "allow" ECMAScript to be the DOM implementation language as well as the author script language.

http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.xml.diff?r1=1.321;r2=1.322;f=h

Regarding comment #1, if the object is not a node (and it isn't), then passing that thing to
appendChild results in an error. What needs fixing?


"In a web page, script that implements the EventListener interface,which is used to register a callback that the DOM Events implementation invokes, would be considered to be a user object."

Missing particle "a". "In a web page" is not needed. I don't know how a script can implement anything, but a user-defined object can be said to implement EventListener, e.g.

var ud = {
 handleEvent : Function.prototype
};

I'm not that comfortable with the term "user object". I usually say "user-defined".

(In reply to comment #10)
> Regarding comment #1, if the object is not a node (and it isn't), then passing
> that thing to
> appendChild results in an error. What needs fixing?

Yes, nothing needed fixing for that case, it already was disallowed.  (I think Jonas was just stating the reasoning behind the then-current wording of the spec.)

> "In a web page, script that implements the EventListener interface,which is
> used to register a callback that the DOM Events implementation invokes, would
> be considered to be a user object."
> 
> Missing particle "a".

I personally don't mind using script as a mass noun.

> "In a web page" is not needed.

I only say "In a web page" so that the use "script" there is necessarily correct.  (In other language bindings, outside of web pages, I wouldn't call them scripts.)

> I don't know how a script
> can implement anything, but a user-defined object can be said to implement
> EventListener, e.g.
> 
> var ud = {
>  handleEvent : Function.prototype
> };

You're right here, script might implement an application of some sort, but it's the objects in the script that implements the IDL interface.  I replaced it with "an ECMAScript object that implements the EventListener interface".

> I'm not that comfortable with the term "user object". I usually say
> "user-defined".

Yeah, "user-defined object" does sound better or more familiar, but I think it could be confused with any ES object the author creates.  Here I want a term that specifically means objects the author creates that are considered to implement IDL interfaces, so I tend to think a "novel" term like "user object" would be better.