Consider adding localNameFilter to MutationObserver

[smaug----]

I was looking at a slow (cross) browser addon code, and one thing they need to do is to figure out when new input elements have been added to the tree.
This means that all the added (and removed) elements are touched, which forces browsers to have
JS wrappers for those and create MutationRecords too.

localNamefilter, similar to attributeFilter would optimize some of that out.
Using css for filtering might be also one option, but it is way more heavy weight in general, so if possible, I'd stick with localNames. (and localNameFilter could be used for text node filtering too, unlike css)

And while addons aren't part of the web, I think web pages have similar use cases.

[annevk]

Using selectors is #77. How would localNameFilter be used for text nodes?

@dtapuska @rniwa thoughts?

[rniwa]

Filtering based on element names sense to me but why not just elementFilter?

Also, should this follow the usual case-insensitive in HTML but case-sensitive in XML semantics?

[smaug----]

How would localNameFilter be used for text nodes?

Er, silly me, that would need to be nodeName, not localName. And since attributeFilter uses localName, elementFilter should too.

I don't care too much about the name. elementFilter would be ok to me. But it should be case sensitive, similar to attributeFilter.

[annevk]

Case-sensitive elementFilter matching on local name sounds fairly straightforward. I could work on specifying that and writing tests, but also happy to hand it to someone else if there's interest since this seems like a nice starter bug.

[hmntptwl]

I am ready to check for this chance.Please authorize me.

[annevk]

@hemant1612 what you want to do is fork this repository and then create a pull request from the fork. The other thing that will need to be done is writing new web-platform-tests.

[zbraniecki]

Filtering based on element names sense to me but why not just elementFilter?

My main issue with elementFilter is that it solves a subclass of the problem and motivates future additions like attributeFilter or combinations for cases where elements and attributes of particular type are expected.

querySelector handle all of that and can be internally optimized by engines for common cases (like elementFilter, attributeFilter etc.) while keeping the "slow case" still faster than doing that in the JS code

[rniwa]

We definitely don't want to execute CSS selectors on every DOM mutation. That's simply non-starter.

[zbraniecki]

That's simply non-starter.

1. Why?

For use cases where someone will put it, it basically means that if they can't get it on the MutationObserver config to be performed (and heavily optimized) by the engine, they'll put it in the callback anyway, because their observer clearly needs it.

If the concern is performance, I fail to understand how is it a win.

2. But, assuming that I'm missing something

Is a combination of localNameFilter and attributeFilter realistic?

[rniwa]

That's simply non-starter.

1. Why?

It would be way too slow.

For use cases where someone will put it, it basically means that if they can't get it on the MutationObserver config to be performed (and heavily optimized) by the engine, they'll put it in the callback anyway, because their observer clearly needs it.

That's okay. Evaluating selectors after the fact is a lot more efficient especially because you'd be executing a lot of them all at once. What's extremely slow is for each DOM mutation to synchronously execute a selector to determine whether a given element should be queued to an observer or not. That's not the kind of work you don't want to be doing for every node being added or removed.

2. But, assuming that I'm missing something
   Is a combination of localNameFilter and attributeFilter realistic?

That's a lot more realistic filtering assuming attribute filter is about filtering based on the presence of an attribute and not its value.

[smaug----]

But it does change the meaning of attributeFilter, if that starts to affect to MutationRecords created because of childList: true.

[rniwa]

@smaug---- Oh yeah, I think we're talking about something different here. It's filtering of records based on attributes, not attributeFilter as it exists today.