Hi Boris. Boris Zbarsky: > I made an attempt to design things using DOMNodeInsertedIntoDocument, and > discovered two major problems. First, and less importantly, event firing > order in the DOM spec is badly underdefined (so it's not clear in which > order DOMNodeInsertedIntoDocument is fired on the nodes of a subtree that's > inserted into the document). Second, it's possible for > DOMNodeInsertedIntoDocument to fire on a node that's not in the document > anymore. While I think it would be nice to have the implementation completely in terms of standard DOM event handling (and I'm trying to use it as much as I can), I don't think it is possible. You also won't be able to use DOMNodeInsertedIntoDocument to handle new bindable elements being inserted into shadow trees, since techinically these aren't a part of the document tree. So I went for using DOMNodeInserted events. But still, DOMNodeInserted events will be stopped when they cross shadow scopes. I ended up having an addUnstoppableEventListenerNS method (which wouldn't be exposed outside of the implementation) to allow capturing DOMNodeInserted events that otherwise would have been stopped. I'm not completely happy with that approach, but I thought it best to utilise the standard event processing as much as possible. Is there some requirement in Mozilla for the sXBL functionality to be kept completely separate from the DOM3 code? If not, then of course you can do whatever you want (intercept appendChild et al) and handling binding at that point. Cameron -- e-mail : cam (at) mcc.id.au icq : 26955922 web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au office : +61399055779 jabber : heycam (at) jabber.orgReceived on Friday, 18 March 2005 04:57:25 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 September 2006 18:11:33 GMT