[whatwg] Events for added nodes while page is loading

Stewart Brodie stewart.brodie at antplc.com
Tue Aug 1 03:15:25 PDT 2006

Robert Græsdal <mail at robbiegee.com> wrote:

> It'd be nice to have an event that'd tell my script when a new dom node  
> have been added to the DOM tree /while it is loading/. Some documents just
> take quite a while to load, so it'd be nice to be able to modify nodes as 

> they were added to the DOM tree.
> I figure we'd need events that fired when the node had been added and  
> closed (meaning that all child nodes have been added and we are about to  
> start on the sibling).

Well DOMNodeInserted(IntoDocument) almost (see below) fits the bill for the
first one.  The latter one is much trickier.  Like you, I also discovered I
needed to know about close tags marking that the parser had finished dealing
with the child nodes in order to handle things that cannot start until their
content is fully parsed, like launching plugins for OBJECT tags (you can't
actually start it up until you've seen all the PARAM elements).  My tree
builder issues a custom event for this when it considers a node's content
complete.  Obviously, I'm looking at this from the browser implementation
point of view, rather than the page author's script's point of view, but
both want the same information.

However, there is still an additional complication of how to handle somebody
using the DOM Node interface to attach entire subtrees - in this case, you
just need to know that the object's content is already complete (because the
child nodes will already be there, you just won't have seen the events yet).
My solution for this was to have an additional property on the
DOMNodeInserted(IntoDocument) events indicating that the tree builder was
responsible for attaching the node.  In effect, this was a signal to the
default event handler that it should wait for one of my custom events to
arrive for that node before dealing with any OBJECT or TEXTAREA element.
I believe that the standard DOM events should always be raised whenever the
DOM tree is modified, whether it be by the parser or by direct modification
of the tree through the Node interface.  This is one area where I disagree
with the WA1 document.  I don't accept the efficiency argument against this:
it is not terribly difficult to optimise away event dispatch if there are no
listeners registered for the event anywhere on that document.  Without such
filtering then, yes, it degrades performance noticeably (on 300MHz devices),
but with it, it's barely measurable.

Stewart Brodie
Software Engineer
ANT Software Limited

More information about the whatwg mailing list