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