> Difficulty of implementations in general, yes. Difficulty of
> individual implementations, no.
The general difficulty is made up of individual ones, normally.
> 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?
> My view is that every implementation of a specification will have
> pain points.
While true, it's a good goal for a spec author to minimize those 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.
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").
> 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.
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).
-Boris