Re: [dom] MutationObserver with querySelector for elements (#77)

It does matter quite a bit when the selector runs.  When adding a child node selector can run
after we've added the node to child or it can actually run as late as just before delivering the MutationRecords, That might even be the case you want, since what if the attributes in the element have been modified after the element was added to the parent node but before MutationRecord delivery - the same selector might not select the element anymore. But then, running the selector so late would be rather big difference to how MutationObserver otherwise works... so I guess selector would need to run right after the element has been added to its parent, and the user of the MutationObserver needs to validate that the selector still applies when MutationRecord is delivered.

Removing a node would require, I guess, running selector before any DOM mutation has happened.

How to make this all perform well? selector matching isn't exactly cheap.
The performance of selectors was one criticism the old Shadow DOM spec got and it is now
using just simple slots.
@heycam @rniwa may have ideas about how to make this for fast.


But, do we want to use selectors. I think I'd be more comfortable with "raw DOM" data.
Filter out based on attributes in the element. childNodeAttributeFilter or some such.
That way the same list of filters could be used for two things, for attribute changes and child node changes.

var filter = ['data-l10n-id', 'data-l10n-args'];
var mo = new MutationObserver(yourCallback);
mo.observe(document, {
  attributes: true,
  attributeFilter: filter,
  childNodes: true,
  childNodeAttributeFilter: filter
});

That would filter out child nodes which don't have the relevant attribute, even in case innerHTML is used.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/77#issuecomment-147072183