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

Re: [D3E] Possible Changes to Mutation Events

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 17 Jul 2008 11:48:52 -0400
Message-ID: <487F69E4.8070203@mit.edu>
To: public-webapps <public-webapps@w3.org>

> 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

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

Received on Thursday, 17 July 2008 15:49:33 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC