Re: [D3E] Possible Changes to Mutation Events

On Thu, 17 Jul 2008 01:46:55 -0400, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
> Kartikaya Gupta wrote:
> > If you did something like
> > document.getElementById('emptyMe').innerHTML = '' and considered it a
> > compound operation, the code above, which works with current
> > implementations, will die because numLinks will be out of sync with
> > document.links.length, and the array indexing will fail. To avoid
> > this scenario, the code has to be rewritten to re-query
> > document.links.length instead of assuming numLinks will always be
> > valid. This is exactly the same problem you're currently having
> 
> With the difference that it's a lot easier to re-query possibly-stale 
> cached information than it is to validate DOM state, sort of.

That's debatable. It depends on the complexity of the web app.

> I should also note that your code, as written, is wrong (gets the wrong 
> indexing in various cases, starting with <a name="">), and that writing 
> it correctly is more work than just not caching the length to start with 
> (and therefore being correct by default).

I realize that, but I wanted to keep the example simple for illustrative purposes. The html didn't have any <a name="">'s for a reason :)

> You might also want to ask web authors whether they prefer being able to 
> write fragile code like in your example or have all their code run 
> faster, of course.  ;)

Web authors will write fragile code regardless (even if they don't want to, they often end up doing so without realizing it). At times it makes me want to cry when I see how much code on the web depends on very specific implementation details of one or two major browsers and is then assumed to work everywhere. But that's another rant for another day...

> > I also consider this entire problem to be more of an implementation
> > detail than anything else.
> 
> I'm not sure what you mean by that.  Difficulty of implementation is an 
> important consideration in spec-writing, generally.
> 
> > 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.
> 
> Thing is, those are the implementations that actually end up being used 
> by users to browse the web.  Of course that brings up constituency 
> issues, etc....

Difficulty of implementations in general, yes. Difficulty of individual implementations, no. 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, and they don't seem to have this problem (also think of the backwards-compatibility nightmare it would be to try and update those implementations if they adopt this proposed D3E, which means they probably won't).

My view is that every implementation of a specification will have pain points. 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. The correct response was to suck it up and do what needed to be done to ensure compatibility AND security AND robustness and all those other good things. It wasn't impossible, merely difficult. But that's life. No reasonable spec can cater to every implementation's idiosyncracies, and clearly there have been lots of other implementations (some of the ones linked above are in C/C++, just like yours) that have managed.

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 (use of meta-languages, or static analysis and code verification tools, or invention of new tools specific to this task, etc.). These other solutions would probably benefit your codebase in other places too. Trying to change the spec to fit your needs, IMHO, seems like the "lazy" solution, and the most likely to cause further complications down the road.

kats

Received on Thursday, 17 July 2008 15:41:01 UTC