Infrequently Noted

I'm back in London on the 14th. Perhaps we can catch up then?

Sounds good. I'll take you out for some real London ale.

Hi, Alex and Anne

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 do not think you need to force the issue. I think most people agree on what we want here (e.g. earlier this year I introduced new Event() and company and got them implemented by WebKit and Opera more recently). As I suggested earlier you should file bugs on the specifications that do not have constructors where you think it would be sensible to have them.

new Element() can have a writable tagName property or allow it to be passed in. That behavior needs specification, but nothing is forcing the issue today. I think you're making my point for me = )

The problem is that what happens with new Element() and e.g. appendChild() if you do not set its local name. And even if you could give a local name its namespace would likely not be what you want and its interface would likely not be what you want either.

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

I think we disagree on the larger point: it's nearly always sane to have a constructor. Saying we should go fight this on a spec-by-spec basis seems incongruous. Sure, we could, but why? WebIDL specifies what should happen in lots of other cases for JS APIs by default (conversions, etc.) which have over-rides.

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.

Namespace? It's HTML. appendChild() can reject what it needs to in any case. And if Element really needs to be a pure virtual, it can take the new [NoConstructor] or whatever. It really is a special case (as is Node)...which means it should be special-case'd ;-)

Alex, sorry, I guess my comment is a bit whiny. :)

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

I think that IDL's purpose is noble, and it should continue to keep that. Having Dash come along shows now, more than ever, we should experiment, and keeping in IDL would do that.

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 think certainly think of quite a few cases where it does not make sense to have a constructor (XMLHttpRequestUpload, XMLHttpRequestEventTarget, Element, Node, CharacterData, EventTarget, EventListener, Window, WindowProxy, Navigator), but my point is that a specification needs to be precise. You cannot just say it will "do the logical thing". Those details need to be defined.

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.

Note that I am not opposed to having this feature, I am just saying that flipping a switch in IDL will not make it work.

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.

Yes, new Image() works precisely because HTML defines those details.

Anne:

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

Anne:

And as the debate progressed, it was clearly explained that new Image() works just fine. The ambient document of the global in question is a workable default. Need something from a different document? Grab it's scripting context or use the factories.

Can we get past debunked arguments already? We have this working in a patch for WebKit without issues. It's not a problem.

Regards

As several people explained to you earlier, HTML would not just have to add [Constructor], but would also need to define which Document object the newly constructed node is associated with (its ownerDocument).

Flipping some switch in IDL will do nothing to make that work.

Hey Dean,

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

You guys should stop pretending that you represent real developers. That stopped being true some time ago. Don't get me wrong, WebIDL is a great idea and I'm glad that it has been specified. But the pace that this spec (and countless others) has been developed, leaves us normal folk gasping for breath. I'm sure that everything is open and above-board but unless you are directly involved it is impossible to keep up.