"What (do you think) is XBL for?"
A very good question.
The way I found XBL in the first place was by answering this question
in reverse. I knew exactly what I wanted to do, and knew that XSL,
XForms, and SVG/CSS/Javascript were not capable of addressing that need.
What I wanted to do was something like this:
<?xml version="1.0" ?>
<xhtml xmlns:my_widgets="http://xseed.us/xbl_lib/widgets_1_0.xbl">
<body>
<my_widgets:menubar>
<my_widgets:menu label="file">
<my_widgets:menu label="open" onmousedown="open('file.xml')" />
<my_widgets:menu label="save" onmousedown="save()" />
</my_widgets:menu>
</my_widgets:menubar>
</body>
</xhtml>
Notice there are no CSS or Script imports. I wanted to encapsulate the
default rendering style, event driven behaviors, and XML descriptions
in a single location, and use namespaces in the main document to avoid
name collisions (such as with the deprecated HTML menu tag). All the
necessary Javascript would be imported by the XBL file, and additional
CSS files could be added to the main document to style XBL defined
tags beyond their defaults.
I also wanted to be able to design an individual tag much like I would
a webpage, with all the imported CSS and Javascript behaving as expected.
And finally it had to be possible for the XML structure of a tag
definition to change without affecting the structure of the main
document. If it DID change the main document's structure, then any
scripts that depended on that structure would need to be changed as
well (This is what shadow nodes provide).
XBL is the technology that came closest to providing these capabilities.
BTW I know I'm using the XML namespace URL in a way it wasn't designed
for. This was the cleanest way I could think of to import a set of
tag definitions into a document, and associate them with a
namespace. If necessary the same could be done with a custom importing
tag like used with scripts.