- From: <bugzilla@jessica.w3.org>
- Date: Tue, 28 Aug 2012 19:51:54 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18533 --- Comment #3 from Dimitri Glazkov <dglazkov@chromium.org> 2012-08-28 19:51:53 UTC --- (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. -- 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 Tuesday, 28 August 2012 19:51:55 UTC