Re: [D3E] Possible Changes to Mutation Events

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?


> 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.

But I want to resolve this soon.  This specification is at the awkward 
point where it's too established to change it much, and too unstable to 
rely on it.  That sucks for everyone.


>> I understand that having the distinction means that you could filter 
>> on the level of depth to fire events on, but I'm asking if this is 
>> useful and necessary.
> 
> I take it you are asking under the general assumption that mutation
> events are useful at all? :)

That is the general tenor of the authors, who, along with users, are my 
chief constituents.


> 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.



Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF

Received on Friday, 18 July 2008 19:42:27 UTC