Doug Schepers wrote:
> Hi, Jeremy-
>
> As I understand it, the advantage of shadow-trees is in their direct
> connection with the source elements, in terms of structure, semantics, and
> liveness.

Ah, yes, that makes sense.

One of my basic objections about the way this stuff is being engineered
is that everything you mentioned is dependent upon being able to
subscribe to changes. There's no reason to lock up this ability in XBL
alone; even within an XBL-implementation proper it would be very useful
to be able to explicitly say "call this code when this changes"; you
might want to make decisions about which callback gets registered, for
instance, or you might want to be able to respond to events not directly
connected to the nodes of this particular XBL object. (This came up for
me a couple of times when I wanted something like an overarching
"table"-type manager, with specialized and sometimes heterogenous table
"rows" and "cells", or when there was something that's a sibling in the
DOM tree that I wanted to attach to some other element's input.)

You are correct that at this time, I can't replicate that feature in
scripting. However, this is not a fundamental advantage of XBL and a
fundamental failure of scripting; this is a failure to expose the
relevant change events to scripting control.

I have also yet to encounter a need for any of that in practice, as a
web developer. Out of curiousity, have you *used* this feature in any
significant way? I'm certainly expecting the answer could be "yes", I'm
genuinely curious.

> I read your XBLinJS page, and the erm... "strongly worded warning"... You
> made some interesting points, but you were mostly attacking a particular
> implementation of XBL, and the very idea of using XML at all. I guess that
> I'm not sure how your library is like XBL. Without condemning your approach
> of converting data via JS (which I use myself), you are eschewing XML,
> removing the bindings, and creating a library (rather than a language). So,
> there isn't an X, B, or L. ;)

My library is like XBL because, excepting the shadow node feature you
mention above, it works just like XBL if you describe what you're doing
with XBL without explicit references to XML. You "create widgets" that
can "bind to nodes" and "respond to events", carry their own specialized
methods, can include each other, can do inheritance (although XBLinJS
gets JS's inheritance model which is unbelievably easier to work with
than the one in Mozilla's XBL), etc.. The design process is the same;
you don't slap down HTML and start hacking together Javascript and
hard-coded event handlers (the old way of doing such things), you create
"widgets" that are much better encapsulated and use those to create the
discrete behaviors you want.

That is, it does the same sorts of things with the same organizational
principles coming into play. Hence, XBLinJS. It is true that it has
neither X nor L (there is some "B", actually, but as there is no direct
browser support it's somewhat more manual, although easily automated;
and that's another thing the broser could support directly, instead of
locking the capability into XBL), but I consider that incidental to the
entire "widgets-in-DOM" that XBL defines.

For what it's worth, I have very little hope or intention of converting
anybody. Mostly I'd be happy if someday XBLinJS makes someone take a
fresh look at XBL and ask why certain things are so darned hard when
they don't have to be, and question whether the putative benefits of the
X outweight the costs.