DOMNodeInserted equivalent event for IE (DOM Updated, DOM Added,...)

[Steve]

Hi all,

In Mozilla & other browsers, I can listen for a DOMNodeInserted (or
other modification) events but of course IE doesn't support this.

I need a method to catch when a node is added to the DOM in IE
(by .innerHTML, .appendChild(), or .insertBefore() ) and I am okay
with proprietary hacks.

I tried document.all (or similar) but it doesn't update with
JavaScript changes after page load. (e.g. putting an onpropertychange
won't work)

I also tried a clever CSS/HTC trick, using the "*" selector, that
triggered a behavior, that fired an event, and this worked just
great!... but this loaded the behavior HTC file for *EVERY* DOM Node,
and it appears in the status bar as 100's and 100's of external file
loads (read: slow and painful).

Finally, I tried using a "*.someClass" selector or
"ElementType.someClass" selector, but these won't trigger the magic
above to catch new elements added to the DOM.

I would prototype something on Element, or HTMLElement, but of course
that won't work in IE either!


Are there any JavaScript Guru's out there that have determined an
elegant solution to this?

If it helps any, it only has to work in IE6.... I can live with it not
working in IE7.

TIA

 

[Thomas 'PointedEars' Lahn]

In Mozilla & other browsers, I can listen for a DOMNodeInserted (or
other modification) events but of course IE doesn't support this.

I need a method to catch when a node is added to the DOM in IE
(by .innerHTML, .appendChild(), or .insertBefore() ) and I am okay
with proprietary hacks.

Since MSHTML sadly does not support any mutation and mutation name event
types to date (not even proprietary ones), you could only check the value of
the `innerHTML' or `outerHTML' properties of the relevant subtree in regular
invervals and see if there was any change.

If it helps any, it only has to work in IE6.... I can live with it not
working in IE7.

The described approach should work at least since IE 5.


PointedEars

 

[Steve]

Since MSHTML sadly does not support any mutation and mutation name event

types to date (not even proprietary ones), you could only check the value of
the `innerHTML' or `outerHTML' properties of the relevant subtree in regular
invervals and see if there was any change.

Thanks Thomas,

I feared as much.

 

[dhtml]

Thanks Thomas,

I feared as much.

You could add some aop before advice around appendChild, insertBefore.

APE.aop.Advice.addBefore(document.body, "appendChild",
function(el) {
el.style.backgroundColor = "red";
});

If you want domUpdated, then you'd have to include removeChild.

Garrett

 

[Thomas 'PointedEars' Lahn]

You could add some aop before advice around appendChild, insertBefore.

APE.aop.Advice.addBefore(document.body, "appendChild",
function(el) {
el.style.backgroundColor = "red";
});

If you want domUpdated, then you'd have to include removeChild.

What are you talking about?


PointedEars

 

[dhtml]

What are you talking about?

AOP Before Advice.

Here you go - an article on AOP:
http://en.wikipedia.org/wiki/Aspect-oriented_programming

I dont really have any good links for AOP in JS that I can remember.
I'm sure if you search around you can find some good ones. I think
there was one on dotvoid.

 

[Thomas 'PointedEars' Lahn]

AOP Before Advice.

Here you go - an article on AOP:
http://en.wikipedia.org/wiki/Aspect-oriented_programming

I dont really have any good links for AOP in JS that I can remember.
I'm sure if you search around you can find some good ones. I think
there was one on dotvoid.

I have heard about AOP before. After having read about AOP I have come to
the conclusion that it is an unsuitable programming concept for client-side
DOM programming in general, and especially here. I'll explain why.

AOP with the DOM requires that a host object's method is overwritten, in
order to insert code that is executed before or after the call without
changing the calling source code. That is always a bad idea.

First, I can see no valid reason why implementors would deliberately choose
to allow methods exposed by interfaces to be overwritten. I would consider
the current possibility of that in some UAs to be the cause of sloppy
implementation at best.

As for ECMAScript implementations, the Specification, since its first
edition, allows a host object to implement it's own [[Put]] method, so
modification of the property value may not even be possible, may very well
cause an error message or any other unknown behavior. Subscribers of *cljs
newsgroups have seen this confirmed at least when they observed that an
assignment to an undeclared identifier, when there is an element with the
same name or ID, causes a runtime error in MSHTML-based user agents. (Which
in turn strengthened the good recommendation that all identifiers be declared.)

As for the goal in question, if we graciously overlook the aforementioned
basic problem, I'm afraid you have overlooked that there are many ways in
which to modify the document tree, of which the least include mutator
methods (of which there are much more than you mentioned). There is a huge
number of writable attributes (implemented as properties) to facilitate
that: Node::nodeValue, Node::textContent, CharacterData::data, Attr::value
from DOM Level 3 Core; StyleSheet::disabled, CSSRule::cssText, and
CSSStyleRule::selectorText from DOM Level 2 Style;
HTMLOptionsCollection::length, HTMLDocument::title, HTMLDocument::cookie(!),
all attributes of the HTMLElement interface and several other HTML element
interfaces, from DOM Level 2 HTML. That is to name just a few. All those
changes cannot be observed with AOP, even if it was generally feasible here.


PointedEars