Re: MutationObserver does not observe state changes

On Wed, Jul 31, 2013 at 10:11 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

>  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.
>

Correct, as long as the user does not need to observe a subtree. If we get
a direct reference to the element, this *can* (does not currently) work
according to spec.


> - Object.observe could work for existing elements, by having them fire
> change records. (This is not specced yet, but hopefully will be.)
>

Correct.


>  - Mutation observers have no mechanism for working on <input> elements'
> checkedness (your original post).
>

Correct.


>  - Mutation observers have no mechanism for working on custom elements
> (your below post).
>

They can observe DOM bound changes, but most complex apps such as
spreadsheets use .value instead of .setAttribute('value', ...)

Does that sum it up?
>

Yes.


>
> 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?
>

Right now, the only way I have seen is to special case .onChange during
tree insertion/removal and mapping the key based on tagName (value,
checked, selected). This is kind of hacky...

Cheers,
Bradley


>  ------------------------------
> *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> 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]
>> *Sent:* Sunday, July 28, 2013 10:30
>> *To:* 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 )****
>>
>> ** **
>>
>> Thanks,****
>>
>> Bradley****
>>
>
>
>