[Bug 23226] New: Need for Virtual MutationRecords

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

            Bug ID: 23226
           Summary: Need for Virtual MutationRecords
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM
          Assignee: annevk@annevk.nl
          Reporter: bradley.meck@gmail.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org

Created attachment 1395
  --> https://www.w3.org/Bugs/Public/attachment.cgi?id=1395&action=edit
IRC Discussion About Topic

I am still a bit new to writing to standards groups so please forgive any faux
pas I make in this report.

Right now various state changes are not observable using MutationObservers, in
particular: <input>, <textarea>, and <select> states/values. These are visible
if we listen to "change" events, but do not provide a clear abstraction for:

* the name of the host object property that represents the state
* the old value
* the new value

After some time and discussion on the mailing list, it was shown that we cannot
fix the getter/setter specification for these various host properties. So, as a
counter proposal an opt-in way to notify observers of host object state changes
seems the best way to bring back what I consider a base use case of
MutationObservers. After more discussion some points came up as important:

* A full event dispatch appears to be overkill because propagation, prevention,
bubbling, etc. are not necessary when compiling a list of MutationRecords for
MutationObservers.
* There should be a clear distinction of host object properties/getters/setters
and DOM Node attributes.

There appears to be some tooling for web inspection of various browsers
allowing enumeration of MutationObservers viewing a Node (when in privileged
code), but this sounds a little extreme to me especially considering the lack
of ability for people to see what EventListeners are on a Node.

Therefore, I propose something like smaug mentioned in the #whatwg IRC:

* node.notifyMutationObservers({property: "value"});

Which would create something like:

{property:"value", target: node, type: "virtual"}

If it is determined that old/new values and or arbitrary data are relevant to
this, I would think that to be amenable.

This would create a mutation record with a specified type such as "virtual"
that would be propagated to any MutationObservers watching a Node.

By doing this, we add an addendum to elements that use "change" events so that
they fire these virtual records without affecting older code. This also may
become relevant with WebComponents needing to announce state transitions, that
are not directly observable in the DOM.

As always I am completely open to alternatives that would cover these use
cases.

Cheers,
Bradley

Related History:

http://w3-org.9356.n7.nabble.com/MutationObserver-does-not-observe-state-changes-tt260972.html#none

https://code.google.com/p/chromium/issues/detail?id=260881&can=1&q=reporter%3Abradley.meck&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 12 September 2013 18:51:23 UTC