Jeremy Bowers:
> Interesting. If I'm reading the definition of "shadow tree" correctly,
> I consider it one of the *advantages* of XBLinJS that it uses *real*
> nodes and not half-implemented "shadow" nodes.
>
> My experience was with Mozilla around 1.7, and the shadow node
> implementation was disasterously buggy, compared to real nodes.
>
> Can you tell me why you *need* "shadow trees", rather than real DOM
> nodes created via createElement?

In a word, encapsulation. Having the shadow nodes inside a shadow tree
that is connected to the element, and not in the real DOM, affords some
level of encapsulation. True, it's not that well encapsulated because
you can always get to the shadow content through an attribute on the
bound element, but it does keep the implementation elements separate
from the main DOM.

> (My goal with XBLinJS is to have a *real* feature match with XBL, not
> to match implementation-detail for implementation-detail. If "shadow
> nodes" are just "how it's done" and not an actual feature of some kind
> providing direct benefit to the end programmer, I don't consider "it's
> missing shadow nodes" to be a valid criticism.)

Sure, I don't think shadow trees are really necessary for
form/presentation separation. It's just a bit cleaner, IMO. Especially
when you have nested bound elements.

--
Cameron McCormack ICQ: 26955922
cam (at) mcc.id.au MSN: cam (at) mcc.id.au
http://mcc.id.au/ JBR: heycam (at) jabber.org