During a bit of development downtime here, I've been working on making XBLinJS work on any ol' DOM nodes, not just HTML ones. Which, most notably today, means that you can in theory use XBLinJS as a drop-in replacement for the actual, factual XBL. It also means it can be used with other document structures that use DOM and the same basic event structure, like perhaps SVG someday. If we're extra good developers, we may someday see widgets that successfully integrate both XUL and SVG at the same time. Maybe even cross-browser...? Please?

Mostly it involves turning some document.createElement calls into document.createElementNS calls, and a little (very little!) bit of bookkeeping to decide which to use. (createElementNS is DOM2, which not all browsers support, so I can't require it, but you can't use DOM reasonably in a modern XML document without it.)

Which means, hooray!, another set of quirks to deal with. Because if you think that XUL might be implemented as a kind of super-HTML, almost identically implemented but with extra widgets, boy would you ever be wrong! Functionally, it's much more like an extra wimpy HTML, only with extra widgets that are extra likely to crash the browser or randomly and untracably fail. The theoretical power is greater, and you can certainly realize much of it, but what ought to be unmitigated benefits (especially as you can embed arbitrary XHTML in XUL) is severely weakened by its spotty implementation.

I had some real trouble with the getting the events to register correctly, but fortunately, while XUL doesn't like node.onclick for a node that isn't yet on the screen (more "it has to be rendered for it to be real" crapola that I remember from my XBL days), you can use addEventListener.

If these target-specific hacks start piling up, I'll factor them out into a support "Flavor" object so they don't clutter up the code and you can just load the one you want, but so far they are limited and can't add more than a couple hundred bytes to the compressed code. We'll see if they stay that way. (I'm currently guessing 50/50 there will be something like this in 0.4.)

In other news, I stumbled across this Javascript shell which is much nicer than the one I had before. It is compatibly licensed, so I am also currently sucking it into XBLinJS and 0.4 should have a much nicer HTML JS console. An interesting experiment, if I get bored, will be to try to get that working in XUL by labeling all of the nodes with the XHTML namespace and see what happens. It ought to work, in theory, except the event processing may be borked.

The XUL-support stuff is in CVS, but poorly tested. (My plan is to get to the point where a person who cares about XUL can do something real, but not necessarily perfectly, which is a pre-requisite for anyone to care.) The extra JS console, not for the moment.