W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [D3E] Possible Changes to Mutation Events

From: Kartikaya Gupta <lists.webapps@stakface.com>
Date: Thu, 17 Jul 2008 20:31:44 +0000
To: Boris Zbarsky <bzbarsky@MIT.EDU>
Cc: public-webapps <public-webapps@w3.org>
Message-ID: <E1KJa98-0007wH-5J@maggie.w3.org>

On Thu, 17 Jul 2008 11:48:52 -0400, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
> 
> > There are countless other
> > implementations of MutationEvents out in the world
> > (http://google.com/codesearch?hl=en&lr=&q=DOMNodeRemoved+-mozilla+-webcore&sbtn=Search).
> > They exist in more languages and are used in more contexts than I
> > care to enumerate
> 
> That's fine.  How many of those contexts have to assume that all DOM
> access is malicious?

More than zero, I think. There's at least one gtk implementation that (at a quick glance) would have to deal with potentially malicious users.

> > I've run across at least a dozen things in the DOM specs
> > that I would have liked to change to make my life easier to make my
> > code more robust. The correct response for me in those situations was
> > not to request changes to the spec.
> 
> Why not, exactly?  That's exactly what implementation feedback is all
> about... (granted, it's easier to do this with specs that are not "final").

Because I don't think the spec is bad. It's consistent, useful, and makes sense to me conceptually. If I managed to paint myself into a corner while implementing it, that doesn't mean the spec is wrong or needs changing.

> > If compliance with the spec necessarily introduced security issues,
> > then I would agree that the spec should be changed. In this case,
> > however, I think your problem is better solved in other
> > implementation-specific ways
> 
> For example, removal of support for this particular specification?
> That's being a very tempting option, as Jonas said.

If that's your choice, then so be it. As it is, the changes you're proposing will (I think) make the spec far less useful to authors and significantly reduce adoption and use of Mutation events. I would prefer to see you guys leave the current spec as-is, not implement it, and instead create and implement a new spec with your desired behavior that doesn't have to deal with backwards compatibility. Just create DOMNodeRemovedPost events or something.

> That said, we are in fact doing the things that you mention in terms of
> static analysis, etc, etc.  The issue with mutation events is not that
> they can't be made safe, it's that doing so is expensive enough that
> they're just not worth it, especially given the various other issues
> they have (such as the fact that the author can't rely on most of the
> information in them).
> 

Again, if they're that useless already then it doesn't make sense to introduce additional compatibility issues and further reduce their usefulness.

kats
Received on Thursday, 17 July 2008 20:32:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT