From sorvell@:

What about doing it like the - o so cool - mutation observers?

You get a single event containing a list of upgraded component definitions. Then perhaps if we end up supporting lazy loading component definitions, you'd get the same event with the new list of upgraded components.

(In reply to comment #0)
> When an element definition is upgraded, should we fire an event for:
> 
> a) each specific instance upgrade -- seems like too much

In theory the component itself could provide hooks in its constructor to provide a callback, or dispatch a custom event on itself.

> b) when upgrade of all elements to a specific definition is complete

I can’t really think of the use case for this. When would you want to do this?

> c) when all upgrades of all known definitions are complete?

This would be useful because at that point you can detect errors, if any elements you expected to be upgraded have not been upgraded. Does it make sense to expose a nodelist of elements needing upgrade?

(In reply to comment #1)
> From sorvell@:
> 
> What about doing it like the - o so cool - mutation observers?
> 
> You get a single event containing a list of upgraded component definitions.
> Then perhaps if we end up supporting lazy loading component definitions, you'd
> get the same event with the new list of upgraded components.

I think the crucial datum in the proposed event is relating the old element with the upgraded replacement. So I think one of the mutations (removal or insertion) would need an extra property indicating the replacement/replaced element.

I think a new kind of mutation isn’t desirable because it would be nice if something using Mutation Observers to look for any kind of change doesn’t need to map an "upgrade" mutation to a removal and insertion.

(In reply to comment #2)

> > b) when upgrade of all elements to a specific definition is complete
> 
> I can’t really think of the use case for this. When would you want to do this?

To know when you can use an element of this type.

> 
> > c) when all upgrades of all known definitions are complete?
> 
> This would be useful because at that point you can detect errors, if any
> elements you expected to be upgraded have not been upgraded. Does it make sense
> to expose a nodelist of elements needing upgrade?

To detect errors, hook b to track each definition, then look in c to ensure all are good. Right?

> 
> (In reply to comment #1)
> > From sorvell@:
> > 
> > What about doing it like the - o so cool - mutation observers?
> > 
> > You get a single event containing a list of upgraded component definitions.
> > Then perhaps if we end up supporting lazy loading component definitions, you'd
> > get the same event with the new list of upgraded components.
> 
> I think the crucial datum in the proposed event is relating the old element
> with the upgraded replacement. So I think one of the mutations (removal or
> insertion) would need an extra property indicating the replacement/replaced
> element.
> 
> I think a new kind of mutation isn’t desirable because it would be nice if
> something using Mutation Observers to look for any kind of change doesn’t need
> to map an "upgrade" mutation to a removal and insertion.

it sounds like you're saying "is" desirable, not "isn't". Can you explain this a bit more?

For now, I am just wiring two simple events for b and c. We can revisit when we have actual stuff to play with in Mozilla and WebKit.

Filed bug 18721 to track c. B is already spec'd as elementupgrade event.