[dom] The NodeFilter callback interface doesn't make sense (#186)

https://dom.spec.whatwg.org/#interface-nodefilter

Quoting a [Blink commit message](https://chromium.googlesource.com/chromium/src.git/+/d5996673c3f101a6dc8b2e50d9b74e32ba59a731) I wrote:
```
NodeFilter is a callback interface in the spec, but a plain interface in
Blink. It's the only callback interface that also has attributes, so
that there must be a NodeFilter attribute on the global object. In order
to make NodeFilter a callback interface per spec, the bindings generator
would need new code to generate that object.

If it's possible to make the createNodeIterator() and createTreeWalker()
filter arguments callback functions instead of callback interfaces, it
looks like this could all be simplified significantly. NodeFilter would
then remain as a plain interface with only the const attributes.

There is also a minor incompatiblity with Gecko related to NodeFilter.
Blink always wraps the function or object inside a new object which is
instanceof NodeFilter, and NodeIterator.prototype.filter returns this
object. Gecko, on the other hand, returns the same object thas was
passed in to createNodeIterator(), and instanceof NodeFilter throws a
TypeError.
```

As it turns out, the usage was for too high to consider such changes. Quoting a [Chromium issue comment](https://bugs.chromium.org/p/chromium/issues/detail?id=591919#c2):
> While chromstatus.com is not updating, @RByers helped me check usage from the stable channel internally:
> NodeFilterIsFunction - 0.82%
> NodeFilterIsObject - 0.039%
>
> As expected, making this a plain callback function is out of the question, the current behavior needs to be preserved. I'll file a spec bug.

So, now the trouble is that this doesn't make much sense and I wonder if it could be tweaked somehow. Is what Gecko does how this is intended to work?

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