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

It might be simpler to have a separate selector observer mechanism, i.e. something that just watches for changes to the set of elements in a subtree that match the given selectors, and not be a filter on the existing fields on a MutationRecord.

Then we can just require the mutation observer records be generated whenever the element is restyled, and use the restyle process to do the "element now matching" / "element no longer matching" checks.  It would mean that a sequence like:

```
observe e for ".x" change;
e.className.toggle("x");
e.className.toggle("x");
```

wouldn't generate a record, while:

```
observe e for ".x" change;
e.className.toggle("x");
e.offsetTop;
e.className.toggle("x");
```

would generate two (and possibly be coalesced?  I think the way MutationObserver works allows for this kind of coalescing).

I don't think selector observers need to be more expensive than the selector matching we do for restyles, especially if we're modelling whether an element matches one of these selectors or not is done by pretending we have a style rule in the document with the relevant selector (and some hack to make it rooted at the root of the observation).  I think the performance impact of adding a real style rule to a document being about the same as one for selector observers is reasonable.

The observer probably needs to maintain a set of elements that currently match, so that when an element is removed from the tree we remove it (and its descendants) from the set.

We'd also need to do something different for elements in display:none subtrees, which Gecko doesn't give styles unless script does a getComputedStyle, and we'd probably need to adjust the restyle process to get that to work...

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