- From: Cameron McCormack <cam-www-svg@aka.mcc.id.au>
- Date: Fri, 18 Mar 2005 15:57:16 +1100
- To: www-svg@w3.org
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.org
Received on Friday, 18 March 2005 04:57:25 UTC