[whatwg/dom] Allow `MutationObserver` to observe (certain) element property changes (Issue #1340)

### What problem are you trying to solve?

Some elements have an internal state that can change. Think of a checkbox whose `checked` property gets updated as you check/uncheck this.

This type of change is not observable by `MutationObserver` because this mutation is not reflected in the DOM tree: it’s only the property that gets updated, not the attribute.

I would love to be able to respond to this type of change with a `MutationObserver` because of the timing of the `MutationObserver` callback: it’s a microtask. This allows me to respond to a change before any of the rendering steps are executed.

In my use-case specifically, I’d use this to [automatically trigger View Transitions](https://www.bram.us/2024/11/25/experiment-automatically-triggered-view-transitions-with-mutationobserver/). Other use-cases could be to do something like form field validation.

### What solutions exist today?

Workarounds include listening for specific events on those elements. For `input` for example this is the `click` event (and not `change` because that fires too late), which you can hijack to be able to respond to it. This is cumbersome to implement as not all browsers/platforms respond in the same way, and not all elements/properties can use the same event.

Some other hacks/workarounds such as responding to a selector match changing exist (see [here](https://www.bram.us/2024/11/25/experiment-automatically-triggered-view-transitions-with-mutationobserver/#shortcomings)) but these rely on going round the event loop once. Because of that, the code to respond to a DOM property mutation fires _after_ a frame already got rendered, which is too late for this use-case.

Other workarounds [suggest to override the getter and setter](https://stackoverflow.com/a/68426166/2076595) which is not something that I would not recommend + it also doesn’t work with the property being changed not by code (as in: you actually clicking it).

### How would you solve it?

A new boolean in the `MutationObserverInit` dictionary to enable/disable monitoring DOM properties.

Maybe, for performance reasons, instead of a boolean this could be an array of strings resembling the properties that the author wants to monitor – like `attributeFilter`.

Additionally, the list of observable properties could be limited to a predefined list that only reflect the element’s _state_. For all inputs that would be `value`, for checkboxes/radio buttons that would be `checked`, for select elements `selectedIndex`, etc. This would make the feature less of a performance footgun when used.

### Anything else?

An alternative approach could be to reflect changes to a state (such as a checkbox getting checked) in the markup, by actually updating the attribute synchronously as well so that an (unmodified) `MutationObserver` can respond to the change.

For text inputs specifically this synchronization could be enforced trough the proposed `beforechange` event _(see https://github.com/whatwg/html/issues/10639)_. Ideally, it would have a more generic solution that can cater for many more properties and types of elements.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1340
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1340@github.com>