Well, elementupgrade isn't any kind of change to DOM, so using mutation observer
for it feels a bit like misuse of the API.

(In reply to comment #1)
> Well, elementupgrade isn't any kind of change to DOM, so using mutation
> observer
> for it feels a bit like misuse of the API.

It totally is a DOM change, right? There's a whole bunch of replacement that happened and the DOM node that fires elementupgrade has just been inserted into DOM.

The biggest issue here is that upgrading a tree full of custom elements would be incredibly chatty and slow. Elliot pointed out that this event sounds a lot like a mutation event.

Replacements are DOM mutations and of course there will be a mutation record
for each node removal or insertion. They are just normal DOM mutations.
But upgrade itself isn't a DOM mutation.

upgrade event sounds more like load event.

(In reply to comment #4)
> Replacements are DOM mutations and of course there will be a mutation record
> for each node removal or insertion. They are just normal DOM mutations.
> But upgrade itself isn't a DOM mutation.

But the upgrade algorithm specifically suppresses these mutation records now: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-element-upgrade

Oh, that sounds like a bug.

(In reply to comment #7)
> Oh, that sounds like a bug.

My thinking here was to keep element upgrade as quiet and least side-effectey as possible, and only signal when the upgrade is done.

Also, in cases when we (the browser) know that the author doesn't hold JS references to the element that's being replaced, we (the browser) don't _need_ to do actually do any replacing. In which case, we don't have to generate artificial mutation records.

Mutation observer is about observing changes to DOM.
Special cases make the API inconsistent, and inconsistency in APIs should
be avoided.
If you don't want to get mutation records, don't observe those elements.

What we could do perhaps is to add some kind of filter to MutationObserver,
but not sure it would help much in this case.

I think you need to minimize the time between when the new element is inserted into the DOM but the custom element’s code has not run.

Specifically, if that window is non-zero, JavaScript has to be prepared to handle custom elements in *three* states: not upgraded, "half upgraded" (after the DOM modification but before the notification), and upgraded. Handling a third state will be tedious and confusing.

For this reason I think an upgrade event is better than a MutationObserver, because we have more control over the timing of the upgrade event and can fire it "immediately".

Such an event goes against the rationale for deprecating mutation events in favor of MutationObservers in the first place–that the nesting of such events is confusing, etc.

I believe that argument does not apply in this case, because the UA can control when it fires upgrade events so that they are never nested.

(In reply to comment #10)

The discussion about suppressing mutation events is in bug 20490.

elementupgrade is no more. The upgrade process has been replaced with prototype swizzling.