add changed value to mutation record

[andreasplesch]

https://www.w3.org/TR/dom/#interface-mutationrecord

A sequence of mutations observed and recorded by a mutation observer may involve the same attribute twice. Say a timer element is observed and suffers this sequence:

timer.setAttribute('enabled', false);
timer.setAttribute('cycleInterval', 10);    
timer.setAttribute('enabled', true);

The callback of the mutation observer then is invoked after the 'enabled' attribute is reset to true, and the sequence of mutations passed to the callback includes all three changes. Currently, the callback cannot know that the 'enabled' value was set to false after the first change occurred. Information is lost.

As a remedy, the MutationRecord interface could include a
readonly attribute DOMString? value;
attribute which holds the value of the changed attribute at the time when the record was observed. This way the sequence of recorded mutations contains a complete history and no information is lost.

[andreasplesch]

Some history:
https://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1622.html
https://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1686.html
https://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0779.html

It looks like one of the motivations for introducing mutation observer was the idea that it is more efficient to respond to the net effect of mutations rather than to each individually.

Since there are cases when the sequence of mutations is as important as the net effect of the mutations, there is a need for mutation events or for options for mutation observer.

[annevk]

Can't you do this by observing oldValue?

[andreasplesch]

In the callback I think it should be possible to go through the sequence of mutation records, look for mutations that affected the same attribute multiple times, and use .oldValue of future mutations to determine the value of attributes at the time of their mutation. I just tried this and it seems to work.
Such a procedure does read and feel more like a work-around for something that should be straightforward. A .value mutation record property seems like a reasonable expectation and even may help in adoption. But ultimately it would be a convenience property.

[annevk]

But just like oldValue it would be expensive and not there by default, at which point you might as well use oldValue. Closing this since the current API seems fine for this case.

[andreasplesch]

Fair enough if really expensive. Thanks for responding quickly.