Summary

  • The W3C’s 2012 DOM4 draft described mutation observers and record queues. Its 2015 Recommendation explicitly presented Mutation Observers as the replacement for Mutation Events.
  • The current DOM Standard lets authors watch selected child-list, attribute or text changes, including changes in a subtree. The browser queues records and delivers them at a microtask checkpoint; authors choose how to reconcile their components with what changed.

Imagine a page assembling a list of meeting cards. It inserts one card, changes a label on another, removes an expired meeting and updates a count. A script watching the list wants to refresh its index after those edits. If every tiny change rings a synchronous bell, the watcher can run in the middle of the page’s rearrangement, seeing furniture in transit. A packet of change records gives it a much better moment to look at the room.

The W3C DOM4 Working Draft of 6 December 2012 already described mutation observers. It defined an observer’s record queue, observation options and operations for stopping observation or taking pending records. The mechanism tracked which nodes changed and how that news would reach interested code. The W3C publication history places that draft in the run of DOM4 documents that later led to a Recommendation.

The DOM4 Recommendation of 19 November 2015 stated the change in its abstract: Mutation Observers replace Mutation Events. The replacement was an architectural choice. Instead of making a DOM edit announce itself through a separate event at the point of change, the standard queues MutationRecord objects for observers that registered interest. It then queues a compound microtask to notify them. One round of page work can therefore generate a list of records for a callback to examine together.

The observer chooses its beat. It can ask about children added or removed with childList, attribute changes with attributes, or changed text with characterData. subtree broadens the watch from the target to its descendants. Filters can narrow the attributes of interest; old-value options can preserve prior attribute or text values in the record. The library that owns the meeting list can subscribe to the part of the tree it actually maintains.

A record carries a type and a target. Depending on the change, it may include added or removed nodes, adjacent siblings, an attribute name or an old value. The meeting index can examine the packet, decide which cards need attention and update its own data. The browser provides the envelope and the delivery schedule; the page code decides what the news means. The records supply the selected changes according to the observer’s options.

The WHATWG DOM Living Standard carries the present form of the mechanism. It queues a microtask to notify mutation observers, gathers pending observers and delivers their record queues to callbacks. takeRecords() returns and empties an observer’s pending queue when code needs to collect it directly. disconnect() ends observation and clears queued records. Those methods make the subscription part of a component’s lifecycle: watch while the list exists, drain or stop when its job changes, and avoid receiving stale mail after moving out.

The W3C’s DOM4 publication history also records that its snapshot was retired in 2020. The living DOM text continues to define the observer mechanism. That distinction matters when reading an archive: the 2015 Recommendation anchors the moment when Mutation Observers were formally cast as the successor to Mutation Events, while the current algorithms live in an actively maintained standard.

What did the browser invent here? A small common postal service for a page that rearranges itself. The service tells the meeting-list author which selected parts of the tree changed, and delivers the records at a defined point after the edits have been queued. The author decides how to maintain the index. The difference between a doorbell and a mailbag is modest until a page starts moving a hundred pieces of furniture at once.