RE: MutationObserver does not observe state changes

To make sure I'm understanding the question, here's the situation as I see it:

- Object.observe will work for custom elements with hidden state, if their authors are careful to fire change records on the appropriate properties.
- Object.observe could work for existing elements, by having them fire change records. (This is not specced yet, but hopefully will be.)
- Mutation observers have no mechanism for working on <input> elements' checkedness (your original post).
- Mutation observers have no mechanism for working on custom elements (your below post).

Does that sum it up?

I agree that this seems like a pretty bad hole in mutation observers and would love to hear some perspective from others on the list.

I wonder how Polymer/MDV do "databinding" to e.g. the checked property of an input; do they just have a list of properties they need to special-case, and can't bind to attributes directly?

________________________________
From: Bradley Meck [bradley.meck@gmail.com]
Sent: Wednesday, July 31, 2013 10:46
To: www-dom@w3.org
Subject: MutationObserver does not observe state changes

So, it seems that the JS API could fire change records for the host objects to listen to on Object.observe, but what about something to detect that this Object.observe is needed if you are listening to a subtree.

Well then, this still leads to the questions on the DOM side of things; in particular, what to do with "hidden" state like Shadow DOM like fragments / WebComponents that may have attribute initializers, but do not specifically update the Attr itself. How would the author of a WebComponent tell the DOM to emit a MutationRecord due to a state change representing what the HTML was initialized with has changed, but the DOM has not updated the Attr. In the past updating AttributeNodes on the DOM was costly if performed often enough, very costly on spreadsheet applications for example.


On Sun, Jul 28, 2013 at 3:10 PM, Domenic Denicola <domenic@domenicdenicola.com<mailto:domenic@domenicdenicola.com>> wrote:

There is, in theory, nothing that prevents this from working at least in the case of Object.observe, given that  objects can fire their own change records. Indeed, that capability is designed specifically to handle the getter/setter case.



From: Bradley Meck [mailto:bradley.meck@gmail.com<mailto:bradley.meck@gmail.com>]
Sent: Sunday, July 28, 2013 10:30
To: www-dom@w3.org<mailto:www-dom@w3.org>
Subject: MutationObserver does not observe state changes



Both MutationObservers *and* Object.observe are unable to listen for changes to state on <input> elements and the like. This seems like a pretty fundamental thing, to have one of these work (if not both). I expect most people to encounter some surprise when setting the state of an element but not observing them. I have come up with some questions due to this.



1. What is the official reason this is not supported?

2. Will there be a change due to this seemingly being a common expectation?

3. How should custom elements that have state be treated?

3. 1. Should stateful elements have to write to attributes to be observed?

3. 2. Should stateful elements write to host objects directly to be observed?



I have heard the following reasons (for checkboxes) that do not fully cover these points:



.checked etc. is a JS getter on the element. ( https://code.google.com/p/chromium/issues/detail?id=260881&can=1&q=mutationobservers&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified )

.checked does not map to an attribute ( https://bugzilla.mozilla.org/show_bug.cgi?id=898428  )

MutationObservers are not to observe state, only DOM ( irc.freenode.net#w3c<http://irc.freenode.net#w3c> )



Thanks,

Bradley