Re: [D3E] Possible Changes to Mutation Events

On Jul 16, 2008, at 10:33 PM, Kartikaya Gupta wrote:

>
> You could argue that this example is contrived (and it is), but I  
> think it still illustrates the point. The current interleaving of  
> mutations and events is bad for (some) implementations and good for  
> web authors. Your proposed interleaving is good for (some)  
> implementations and bad for web authors. In both cases it's for the  
> same reason - being able to make assumptions simplifies code, so the  
> side that gets to make those assumptions is better off, and the  
> other side has to revalidate their assumptions.

That would be a valid argument if mutation events were good for Web  
developers in the first place. But they are pretty hard to use either  
way, and generally are unused by most content. Like the Mozilla  
developers who have posted on this thread, I consider them a marginal- 
value feature.

> I also consider this entire problem to be more of an implementation  
> detail than anything else. The current spec can pose a security risk  
> if not properly implemented, but that's true of any spec. The  
> security risk identified is only a problem on C/C++ implementations.  
> Speaking as a Java implementor, I prefer the spec as it stands now.  
> It is far easier to simpler for me to assume listeners don't mutate  
> the DOM, and then catch any exceptions that get thrown when that  
> assumption is violated. With the proposed changes, I would have to  
> implement some complicated queuing solution that increases memory  
> requirements dramatically.

There's almost certainly some cases where such an approach will lead  
to wrong behavior instead of an exception. Since your implementation  
takes the ostrich approach, I don't consider this very strong evidence  
of the spec being easy to implement in any language.

Regards,
Maciej

Received on Thursday, 17 July 2008 22:03:46 UTC