Phase2Results.php" ); ?> Mutation Events - RuntimeWiki

Mutation Events

From RuntimeWiki

Jump to: navigation, search



API Support for Mutation Events

Detailed write-up


Right now there is no API support for mutation events from browsers. When a node is added/removed/changed in the browser DOM, developers will not know about it until the developer "polls" the DOM. This lack of support for mutation events makes it difficult to write sophisticated dynamic applications. The browsers already know when a new item is added to a DOM, it would be extremely helpful to Javascript developers to get notified for such events.

Why Is This Important?

Ajax application development is largely about manipulating the DOM dynamically. This is distinctly different from Web 1.0 applications where the DOM is more or less static. Given that the DOM is being manipulated by JavaScript code dynamically, the ability for developers to get notified when DOM mutation happens is naturally being called for in order to create more sophisticated Ajax applications.

For example, JavaScript toolkits are undertaking the task for providing better layout management because current browsers provide only rudimentary layout management support (via "table" or CSS only). In order to manage layout, JavaScript developers need to have real-time knowledge of DOM component creation/additional/removal. Right now there is no easy way for achieving so.

Screen readers

At the recent OpenAjax F2F meeting, Bertrand Le Roy pointed out that good support for screen readers requires support for mutation events, and said the IE8 supports mutation events for screen readers, but not yet for JavaScript.

Real-time Collaboration editors

Synchroedit uses DOM mutation events in Firefox + a Comet channel to do collaborative shared editing of web documents. DOM mutation events are a great way to do this, simply capturing them, sending them to the server, then spraying them out to other web clients that subscribe to a user's edits. If IE supported this then this approach could be used for collaborative editing there.

Possible Solutions

Comment #1: Browsers might start by supporting DOM mutation events universally according to spec DOM3 Events. Of course, DOM3 Events assumed XML namespaces, but that's probably orthogonal to raising mutation events on an HTML DOM.

Comment #2: I’m not going to suggest in this list that browser vendors should fully figure out HTML tag subclassing since it may require architecture changes. Instead, point solutions like mutation events everywhere will go a long way. For example, adding onCreate, onAdd, onRemove, and onDestroy events for HTML DOM elements that developers can listen to.

Background material that request this feature


Phase I Voting - Vote for Your Top 5 Features

NOTE: PHASE I VOTING IS NOW OPEN. (2008-04-01) We have now changed the voting procedure. Instead of putting votes on each separate wiki page, we are asking people to cast their Phase I Votes on the following wiki page:

Phase II Voting

More about this later.

Personal tools