[Bug 23226] Need for Virtual MutationRecords

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23226

--- Comment #6 from Bradley Meck <bradley.meck@gmail.com> ---
(In reply to Rafael Weinstein from comment #5)
> It's not clear to me why observing a subtree is necessary. Can you please
> explain this?
> 

The original use case problems was that MutationObservers could not view host
object property changes. This came up during a workflow of watching a <form>'s
subtree.

>
> AFACT, The original complaint is that state changes of input elements
> (input.value, select.selectedIndex, etc...) are not directly observable
> (other than by registering event listeners).
>

This is true, but came up when using MutationObservers, if I wanted to merely
listen for these change events on those specific properties I can use a
"change" event handler.

> 
> The original thread you created seemed to resolve in fairly good agreement
> that those elements should emit changeRecords via notifier.notify() when
> their value changes.
> 
> Why is that not sufficient?

Resolve might be a poor word choice here. It was agreed that Object.observe was
a possible solution. However, this is not going to fix the start of the
discussion in which MutationObservers did not watch for state mutation that was
clearly observable.

If we are merely going for sufficient, we could add "change" event handlers on
any DOM insertion/removal of any element that *may* have "change" events and
propagate them to a WeakMap that contains any observers listening to changes,
and iterate up the element that dispatched the "change" event's parent Node
chain and checking against the WeakMap. Then we can detect the type of Node and
what should have changed during a "change" even. Then if we setImmediate and it
looks like the change was not prevented; we can do our work assuming we know
the type of element and it is not something custom.

There is no need to bring notifier.notify() into this if we are ok with the
above; and it would have a similar workflow using notifier.notify() except for
that last 2 steps since we can tell what property changed and it is not
preventable.

This workflow may be simplified with delegating the event listener to the top
of the document, but may cause problems if the observed Node changes documents
that it is in, because then the next document would need to have a "change"
delegating handler on it as well.

This workflow sounds terrible. 

I abandoned the original thread due to talking an many people asking "why"
without listening to the original case. This is my attempt to reassess the
problems I was having, and have seen no progress on. I have spent some time,
not only thinking about the problem but also about the question "why".

Instead of "why" as the question of workflow, "what" may be pertinent to assess
first.

--- "what" is the use case ---

My use case comes from MutationObservers being unable to see state changes that
are clearly available from screen readers, scripting languages, and visible
renders of a page. The cause of this is host objects *for Nodes* containing
internal state. This is likely to become more pressing as custom
elements/document.register begin to standardize more.

--- "why" should we care ---

First of all, this can be done in the way mentioned above. Right now Polymer,
Angular, etc. are implementing it in somewhat similar manners to above. As we
mentioned in the "what" section though, this is going to get increasingly
complex if custom elements start to have "change" events.

Now I like words, and although it may not be the best place to start; a
"MutationObserver" not being able to observe mutation, even if that mutation
notification must be opt-in, seems a little suspect.

An immediate use case, and how I stumbled across this, is when you want to tell
when form data has changed. This gets more convoluted if we have essentially
nested forms with the "form" attribute and no true <form> parent Node. As we
have discussed above, it is possible to just have "change" event handlers on
Nodes / Documents. But having "change" and "mutation" of a Node be entirely
different concepts, that would make me argue for a nomenclature clarification
rather than keeping the word mutation.

Lets delve a little deeper though. These data binding layers are emulating
behavior similar to MutationObservers using events. One of the problems with
events is that they are cancelable, and can make other events queue for
dispatch during their handler. From my previous reading that is part of the
problem of DOMMutationEvent.

Enter Object.observe / notify. These do not suffer the recursive dispatch
problems of an event handler. However, they also do not come with a propagation
up the parent Node chain like events. So doing behavior like watching a <form>
relies on similar tactics of manually firing .notify() up the parent Node
chain.

MutationObservers already fire up the parent Node chain *and* do not suffer the
problems of recursive dispatch and cancellation. Any future custom element may
desire to pass down notifications that match both of these criteria (any input
widget for example that tries to follow what <input>, <select>, and <textarea>
did with .defaultValue for example).

--- "who" has experience with this problem ---

Data binding library authors. I will try to see if some want to loop into this
discussion.

People just learning about MutationObservers; this is quite a shock to most web
developers I have told about MutationObservers.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 13 September 2013 01:54:44 UTC