[Bug 18533] [Custom]: When to fire upgrade events

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18533

Dominic Cooney <dominicc@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dominicc@chromium.org

--- Comment #2 from Dominic Cooney <dominicc@chromium.org> 2012-08-13 03:31:02 UTC ---
(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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 13 August 2012 03:31:04 UTC