Re: sXBL issue -- bindings getting notified when the bound element is inserted into a document

Hi Boris and Cameron,
I have read through this thread and I am still confused about two things:

(1) Boris seems to be saying that in XBL2 a bound element will have 
different methods depending on whether it has been inserted into the 
document or not. Really?

First of all, I should point out that XBL2 doesn't exist quite yet. XBL2 is 
just a vague notion that we will generally add most of the things from 
Mozilla XBL to sXBL, and maybe a couple of other useful features not found 
in Mozilla XBL, but there has been no real discussion yet even about a 
requirements list. In particular, Ian's drafts represent totally unreviewed 
proposals. (However, I hope we can change all of this fairly soon and start 
making progress on XBL2, probably starting off with a discussion of XBL2 
requirements.)

I agree that it is likely that somehow or other XBL2 will allow bindings to 
define methods and DOM attributes for bound elements. Under that 
assumption, thinking ahead to XBL2, doesn't it make sense that these APIs 
would be available at the time the xbl:bound event is raised, no matter 
whether the bound element is inserted into the document or not?

(2) I still don't understand why the binding can't just register a 
DOMNodeInsertedIntoDocument listener on the bound element. I apologize for 
my inability to follow the discussion fully. Is it because 
DOMNodeInsertedIntoDocument results in common scenarios where the node 
might not be in the document anymore, which causes a large percentage of 
developers to have to put in a lot of checks into their scripting logic? 
Boris described a case where a binding is added at the same time that 
script is removing a node. Is this a common case? I am wondering if we can 
at least warn developers about processing model complexities and suggest 
some techniques to avoid these complexities. (I don't believe there is an 
active proposal for extending sXBL. Is there one?)

Jon


At 10:41 PM 3/17/2005, Boris Zbarsky wrote:

> Cameron McCormack wrote:
> > So this is purely from an sXBL author's point of view?
>
> Yes.
>
> > but surely you could just check if it was still there if this mattered (with,
> > for example, Node.compareDocumentPosition).
>
> Surely, but this seems like a huge headache for authors.  Given the number of
> XBL bindings used in the Mozilla user interface that require this information
> (about 20% of the total, last I checked), it seems that it may be worth
> providing this as part of the language instead of having binding authors
> reimplement it every time (which they are likely to do incorrectly).
>
> > I guess I don't see what is special about notifying the binding that the 
> > bound element is inserted into the document.
>
> Because binding authors apparently want to be able to walk the DOM around the
> element the binding is attached to and do something based on the resulting
> information (eg the radio binding in the Mozilla user interface looks for a
> radiogroup containing it and registers with it; that sort of thing).
>
> > To be inserted into the document, it would have to be not in the document
> > tree beforehand.
>
> Right.
>
> > And if that is the case, the binding may as well use the 'bound' event to do
> > whatever it needed to do.
>
> That's assuming that bindings are only attached to elements that are in 
> the document tree.  As long as we're talking about sXBL, where bindings 
> just add shadow content this is reasonable.  In XBL2 or Mozilla XBL, where 
> a binding can implement methods, it seems very odd for methods to appear 
> and disappear based on whether a node is in a document (and even odder to 
> have a node that has some methods, clone it, and have the clone not have 
> the same methods).  By the way, Mozilla XBL currently has some very messed 
> up semantics in this area, and it was while trying to clean those up that 
> I ran into this issue.  I'd really like to avoid XBL2 ending up with a 
> similar mess.
>
> -Boris