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

Re: Mutation events replacement

From: David Flanagan <dflanagan@mozilla.com>
Date: Tue, 05 Jul 2011 12:45:18 -0700
Message-ID: <4E1369CE.5040204@mozilla.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
CC: Olli@pettay.fi, Olli Pettay <Olli.Pettay@helsinki.fi>, Adam Klein <adamk@chromium.org>, Ojan Vafai <ojan@chromium.org>, public-webapps@w3.org
On 7/5/11 12:12 PM, Boris Zbarsky wrote:
> On 7/5/11 3:00 PM, David Flanagan wrote:
>> Boris, you have hinted that making the DOM readonly would cause all
>> kinds of problems, such as: a mutation listener that attempted to set
>> certain global variables would throw an exception. I'm coming at this
>> from the perspective of DOM Core and haven't gotten into the details of
>> HTML yet, so I don't understand what these problems are. Could you
>> provide more detail?
>
> The problem is that web developers don't have a firm grasp on what's 
> part of the DOM and what's part of ECMAScript.  And libraries that 
> hide underlying things don't help it any.
>
> So in practice, a web developer looking at code that involves a set 
> call has no way to tell whether it will work in a given web browser in 
> a mutation listener if listeners disable DOM mutations.  A web 
> developer looking at a function call has no way to tell either.
I've assumed that mutation events are an advanced feature that will 
mostly be used by sophisticated developers and library authors.  But I 
see your point. I was worried you were saying that there quirks to the 
DOM itself that made a read-only mode impractical.

>
> The only way to make it possible to tell without learning every inch 
> of the specs is to not give any access to DOM objects at all from 
> mutation listeners.  Then any code you write there will work.
But that option is completely impossible, right? Not an avenue to 
investigate.

>> Note that this isn't a capability system: we don't have to prevent the
>> listener from having any access to the DOM. That wouldn't be possible
>> and the listeners need read access to the document and its nodes. We
>> just need to make any modification attempts fail.
>
> And I'm saying that this will lead to hard-to-diagnose bustage due to 
> unintended DOM modifications that the caller doesn't even realize are 
> DOM modifications.
>
At least the bustage would fail fast with an exception.  We could define 
a new RECURSIVE_MUTATION_ERR exception code that would make it easy to 
diagnose the problem.

I have to agree with jjb: developers won't like a readonly DOM in 
mutation listeners, but the problems that it will cause are not as bad 
as those that arise when recursive mutations are allowed.

     David

> -Boris
>
Received on Tuesday, 5 July 2011 19:45:46 GMT

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