Re: [D3E] Possible Changes to Mutation Events

Doug Schepers wrote:
> Hi, Jonas-
> Jonas Sicking wrote (on 7/18/08 2:51 PM):
>> Well, I'd start by asking what the rationale is for mutation events at
>> all :) They seem to only solve the very simple cases where all parties
>> that mutate the page cooperate nicely with each other and with the
>> parties that listen to mutation events. But I would have expected that
>> in those cases the parties that mutate the DOM could instead have
>> notified the listening parties directly.
> I admit I've used mutation events only sparingly in my own projects, so 
> I'm not the most qualified to answer.  However, many authors I've talked 
> to or read from speak of them glowingly, so I will defer to the notion 
> that they are useful.
> I know you deal a lot with the more complex mashup cases, but are those 
> really the most common case?  I suspect that even today, the very simple 
> case where only one site is involved are the more common.  Or does "all 
> parties" also mean cases where people are using script frameworks like 
> dojo?

Yes, i mean things like dojo or backbase being separate "parties" from 
each other as well as from the user of those libraries.

I'm still interested to hear why mutation events are better than simply 
crafting your own notifications. But I'm not sure that this is the forum 
for that.

>> In mozilla we have never implemented DOMNodeRemovedFromDocument or
>> DOMNodeInsertedIntoDocument due to its high cost. Likewise I doubt that
>> we'll implement DOMDescendantRemovedFromDocument. I'm not sure what
>> other vendors have done about the old event or feel about the new.
> I am very reluctant to specify something that browser vendors won't 
> implement.  Unless other vendors feel strongly about including it, or 
> Mozilla changes their mind and decides to include it, I'm not going to 
> waste everyone's time by adding this.  The only reason to add a feature 
> is to make sure that authors can use it interoperably, in my mind.  As 
> an author, I was (and am!) always bitter and disappointed when I read 
> about *exactly* the feature I need in a spec, but it's not implemented 
> at all, or not implemented interoperably enough to use.  I have no 
> intention of building up authors expectations like that if it will be 
> futile.
> If possible, I prefer to keep looking for a solution that fits the use 
> cases and will be widely implemented.

Agreed. The only reason I suggested to add 
DOMDescendantRemovedFromDocument was that i was worried people were 
going to scream bloody murder if we deprecate DOMNodeRemovedFromDocument 
without adding something to replace it.

>> Do note that there is still nothing that defines when these events 
>> should fire. I.e. if you do foo.textContent = '', does that fire a 
>> DOMNodeRemoved on all elements before any of them are removed, or does 
>> it fire the event on each of them as they are removed.
>> Though it might not be needed to be defined if the events get 
>> deprecated anyway...
> No, I intend to define that regardless of whether or not we deprecate it.

The two alternatives that I see are:
1. Fire all remove notifications before entering starting compound 
2. Fire each remove notification just before each individual removal 

1 would be a lot better from a security point of view since you avoid 
having to fire events deep inside your algorithms and have the world 
change under you. However it might also be hard to implement since you 
would have to figure out very early on what removals to do, before you 
do them.

I guess I'd recommend 1 in the hope that there are few enough algorithms 
that remove nodes that for each of them you can figure out which 
removals you are going to do beforehand. In mozilla the ones found after 
a quick look was .innerHTML, .textContent, .insertBefore, .appendChild, 
.replaceChild, and some mozilla specific XUL code 
(overlays and templates). The only case that looks complex to figure out 
which elements are going to get removed is the mozilla specific XUL 
code, which shouldn't affect other implementations.

Of course, it's entirely possible that other implementations have other 
complex algorithms that make it hard.

/ Jonas

Received on Friday, 18 July 2008 23:11:10 UTC