Thanks for reporting this, but jQuery cannot provide support to deprecated specs (the mutation events).

That's incredibly disappointing, since there aren't satisfactory replacements for the MutationEvent past the stage of industry proposals.

Replying to [comment:2 anonymous]:

That's incredibly disappointing, since there aren't satisfactory replacements for the MutationEvent past the stage of industry proposals.

The reason $(...).find() modifies the id of an element is to fix some quirks with qSA. There have been some improvements since 1.4.3 and .find() for this specific logic. You might want to try out the current 1.5rc1 release which (depending on your selectors) might trigger less unwanted DSM events.

Personally I think it's not a good idea to rely on a deprecated specification, especially as this one isn't implemented cross-browser anyway nor completely in the browsers which do. So whatever you do is prone to work just in some browsers and for those probably only in specific versions.

Another thing I don't understand is, why you need to look for the target element when a DSM gets triggered?

$("something").bind("DOMSubtreeModified", function( e ) {
  //e.target <-- this should be what you are looking for
});

As a last resort I can propose this very hacky and slow workaround

//this should stop DOMSubtreeModified events triggered by
//jQuery on "something" to bubble up to your DSM handler
//further up the tree
//clearly this comes at a high cost (bind/unbind)
$( "something" )
    .bind( "DOMSubtreeModified", function( e ) {
        e.stopImmediatePropagation();
    })
    .find( "someselector" )
    .unbind( "DOMSubtreeModified" );

Thanks very much for the reply - I've been considering tacks along these lines.

Replying to [comment:3 jitter]:

The reason $(...).find() modifies the id of an element is to fix some quirks with qSA. There have been some improvements since 1.4.3 and .find() for this specific logic. You might want to try out the current 1.5rc1 release which (depending on your selectors) might trigger less unwanted DSM events.

Yeah, I could see that was the purpose. I didn't dig to far in, although I assume that something like setting a custom property on the Element itself wouldn't work, since you can't count on the browser to return the same object. (is that so?)

Personally I think it's not a good idea to rely on a deprecated specification, especially as this one isn't implemented cross-browser anyway nor completely in the browsers which do. So whatever you do is prone to work just in some browsers and for those probably only in specific versions.

DSM is part of a larger, admittedly hacky, solution that does it's best to cope with different browsers. My lower bar here is something along the lines of:

setInterval(250, function() {
  $(document).find(...).etc()
})

If I can't do better than that, I'll fall back to that position. I've been doing pretty well so far :)

Another thing I don't understand is, why you need to look for the target element when a DSM gets triggered?

> $("something").bind("DOMSubtreeModified", function( e ) {
>   //e.target <-- this should be what you are looking for
> });
> 

The trouble is that what I care about are nodes that have been inserted or modified such that they might match a selector - DSM is guaranteed not to target the node inserted, and isn't guaranteed to target anything closer than an ancestor.

I might be able to examine the event to find out what changes occurred, but that's a further reliance on a compliant implementation.

As a last resort I can propose this very hacky and slow workaround

I'm pretty sure I can do better than that. I'm already handling and reducing an event queue to make sure that changes I make in response to a ME don't produce an infinite loop internally. It's possible that I can either tighten that up, or change my handling so that I avoid using jQuery while the event is being processed.