So it would be "parentChainChanged" or some such.
I can see that being useful, especially if it would catch any ancestor change, not just parent change.

Not sure though what kind of MutationRecord would be needed.
Do we need to report which element was attached to which element, or
would just telling the new subtree root be better?
The latter is probably more useful.
(Fast/simple access to subtree root might be useful in any case)

There are three types of changes possible here:

* Parent change
* Ancestor change
* Document change

I would expect a "parent change" notification to be pretty cheap to implement on most platforms.

"document change" is pretty cheap to implement in Gecko currently since we already have an internal notification for that. However that internal notification comes at a pretty high overhead so I'm not sure how cheap it would be to implement elsewhere. And i'm not sure that the internal notification which makes it cheap to implement this in gecko is something that we'll keep around forever.

"ancestor change" I think would be pretty expensive to implement in gecko.


I definitely see value in all three notifications here. But I think that we might want to enable separating expensive notifications from cheap ones. So that you don't incur high costs just because you are interested in for example "parent change".

There's technically also "owner document change". I'm not sure if there are use cases for that though?

In gecko we have ancestor change internally, so it would be rather cheap ;)

I'm reminded of the request that comes up every so often to add a "parent" combinator to CSS Selectors. Somehow Selectors are still super-useful and in nearly every case, you can rearrange your selector logic to avoid needing to do this.

The same seems possible in the scenario Ian provided. I can just observe the document or some scoped parent node to see when my element is inserted.

I suppose there is definitely convenience to observing the ancestor chain changes, but bottom-up matching/tracking is just not a typical pattern used in traversing the DOM.

@Ian, MutationSummary (https://code.google.com/p/mutation-summary/) can provide you exactly the information you are wanting (and do it efficiently) using the existing MutationRecord types.

The idea with MutationObservers was to provide sufficient underlying information so that script can efficiently answer more complex questions.

I'm open to adding more mutation types, but I'm not sure we have a good justification yet.

Also, FWIW, In Blink, document changes are tracked internally at each node. Ancestor changes are not.

I don't understand how I can tell when the element is inserted into another, when that element is either not in a document, or not in a document I know about, which are the cases I am particularly interested in. Also I shouldn't need a 1600+ line library to do this. :-)

The specific use case was having an element that manipulates the parent element, e.g. the way that animations do in SVG. It needs to know when its parent changes, so it can hook in when it's added, and unhook when it's removed.

Ian, it seems custom elements have these hooks. Can we find something that brings that and mutation observers together?

Maybe? I dunno. Neither of those are really in my area of expertise. :-)

The custom element callbacks will provide for this. Perhaps there should be a way to generalize them to builtin elements: https://github.com/w3c/webcomponents/issues/291

Rafael, could you reply to comment 8? Or maybe Adam can?

Re: #8, there is no way to do that with MutationObservers, indeed.

If we want to add something here it does seem like a good idea to add something analogous to what was added for custom elements; adding Domenic who is better-aware of the state of the element lifecycle callbacks (although Anne, you might know too).

We decided this capability was too low-level for custom elements, which now have only (dis)connectedCallback which is about insertions/removals that change an elements in-a-document status. A true inserted/removed hook would be run too often and is not needed nearly as often.

It seems possible to add one in the future (maybe parentChangedCallback?), but it's not clear the use cases are compelling enough. We have one request from Hixie based on an analogy to SVG animations; have we heard authors asking for this?

I don't recall ever hearing author requests for this feature, for whatever that's worth.

(In reply to Domenic Denicola from comment #14)
> It seems possible to add one in the future (maybe parentChangedCallback?),
> but it's not clear the use cases are compelling enough. We have one request
> from Hixie based on an analogy to SVG animations; have we heard authors
> asking for this?

This is a feature request for MutationObservers, not custom elements, so it can't just be a callback on custom element interface as that would not address use cases that invoke non-custom elements.

Going to mark this WONTFIX based on lack of demand. When demand rises, let me know!