Description
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. 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) 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 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 whatwg/html#10639). Ideally, it would have a more generic solution that can cater for many more properties and types of elements.
Activity