Mutation Events

» see w3.org/TR/DOM-Level-2-Events as it lived, on the wayback machine

~ the goodbye ~

The DOM Level 2 Events Recommendation became official on 13 November 2000, and tucked into it was a module for watching the document change. If something inserted a node, removed a node, edited text, or touched an attribute, the browser would fire an event and your code could respond. The names were DOMNodeInserted, DOMNodeRemoved, DOMSubtreeModified, DOMCharacterDataModified, DOMNodeInsertedIntoDocument and DOMNodeRemovedFromDocument.

For a decade this was the only answer to a question that gets asked constantly in real applications: how do I find out that the page changed when I was not the one who changed it. Widget libraries needed it, and so did anything that had to coexist with code it did not control, which in the jQuery era meant a very large amount of the web.

The problem was in the word synchronous. The event fired during the mutation, not after it, so a handler executed while the browser was partway through rebuilding its own tree. Handlers could mutate the tree further and fire more events from inside the first one. The browser had to abandon whole categories of optimization because it could no longer assume that a batch of DOM work would complete without arbitrary script running in the middle. Chrome's own write-up lists the consequences plainly: verbose, fires too often, slow because of event propagation, and a long-standing source of crashes and security bugs.

The replacement arrived in 2012 and inverted the design. MutationObserver batches changes and delivers them asynchronously once the browser has finished its work, which costs you immediacy and buys back everything else. Every modern browser has supported it since 2013. The old events stayed in the platform for another eleven years regardless, deprecated and still perfectly functional.

~ the chronicle ~

~ why they were broken ~

The clearest way to see the flaw is to consider what a handler is allowed to do. DOMNodeRemoved fires before the node actually leaves the tree, so the handler sees a document in an intermediate state and can modify it. Insert a node from inside a removal handler and you fire an insertion event from inside a removal event, from inside whatever operation triggered the removal. Engine code that calls into script in the middle of a tree operation has to be defensive at every step, and the bugs that come out of that are exactly the kind that become security advisories.

There is a reason the spec authors never made any mutation event cancelable, and they wrote it down in 2000: it is very hard to use DOM interfaces that modify a document when any given change might or might not actually take place. That caveat is in the 2000 Recommendation itself, two paragraphs below the feature it describes.

~ the long goodbye ~

The timetable is the interesting part, because standards bodies and browser vendors publish their removals with dates attached in a way that dead products almost never do. The UI Events spec moved mutation events to its legacy section in 2011. Chrome filed a deprecation trial, started printing console warnings that showed up in enterprise software everywhere, and set the removal for Chrome 127, which reached stable on 23 July 2024. For anyone who still needed them, a deprecation trial and a MutationEventsEnabled enterprise policy bought roughly nine more months, expiring with Chrome 135 in April 2025.

Twenty-four years from recommendation to removal, with thirteen of those years spent officially deprecated, is a reasonable measure of how long it takes to get something out of the web platform once it is in.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »