Recently I have been implementing constructors for DOM objects (of course after defining IDL specs:-). Sooner or later I am planning to implement [NamedConstructor] IDL, and then propose specs and implement constructors for HTMLElement, although I have not yet considered the specs in detail. Making HTMLElement constructable is essential to the Component Model (http://wiki.whatwg.org/wiki/Component_Model).

I’d love to meet for a pint. My phone number is still the same.

HOWEVER, working every day with the DOM and the fact that it leaves so much to interpretation, there should be another working group, which specifies how JSDOM works. Because as it goes right now, JS is THE language of the web, however keeping it open for more languages to interact with DOM elements is a good cause.

I think keeping IDL is great, and allowing for a committee to say, “Hey, this is how JS should work with HTML” is worth it. That belongs neither in the HTML spec nor in the ECMAScript spec, and putting it in a middle one would be the best solution.

I’m not sure anyone is pretending anything. I’m saying that it’s pretty tough medicine to swallow that WebIDL is keeping some APIs less idiomatic than they could be. It’s the sort of thing I hope webdevs will appreciate now but I’m not kidding myself. This is pretty inside-baseball.

Anyway, I’m in London. Let me know if you want to get a pint and talk it over.

Regards

That the node document of new HTMLDivElement() is the Document object associated with the global object on which the constructor was invoked is such a detail. new XMLHttpRequest() has something similar. new Event() needs to set the initialized flag.

Before these details are defined they need to be worked out. If you flip a switch in IDL that will not result in them being worked out. [NoConstructor] will just be added all over the place, until it is figured out what should happen.

We don’t go fight those battles door-to-door, why should we do so here?

In any case, it’s not just “meaningful” constructors. DOM is hostile to JS because even default ctors are missing. Yes, we can do better by taking arguments, but the default is nearly always meaningful, so just flipping the bit does have tons of value.

Adding meaningful constructors for existing interfaces is a non-trivial exercise that should not be forced, but rather carefully thought out.

You would also get lots of undefined behavior. new Element(). What is its local name? new Node() or new CharacterData(). What are their types? How do they interact with appendChild()? Etc.

There’s a meta point here, which is why do these memory ownership details need anything but defaults specified for the generated constructors? Maybe we’re just arguing a small point which seems large, but saying “you need to define it” seems to be to be the follow-on from the argument that we should FORCE the issue by causing things to have constructors by default.

Note that I’m not saying that flipping the default is all that needs to happen, only that it’s a necessary first step. Perhaps you don’t agree? If not, I haven’t seen you propose a different mechanism by which to start getting these mis-designs fixed in a systemic way. WebIDL has leverage to force the issue.

Regards