This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
What does "invoking filter" mean when presented with the following one: var filter = function() { return FILTER_ACCEPT; }; filter.acceptNode = function(node) { return FILTER_SKIP; };
There should be no "invoking filter". There should just be calling of the acceptNode method on filter....
Implementations will either take a Function or an Object with the acceptNode function for the filter parameter, so it's not just about calling the acceptNode method. The spec has a note for that effect already. However, when both are offered, implementations will use the function directly (ie the filter will return FILTER_ACCEPT in this case) and acceptNode will not get called. The spec is however silent on which one to choose.
No, implementations take an instance of the NodeFilter callback interface, which always has an acceptNode method. This is a single-operation callback interface, which means you can pass in a function as an implementation of it in the ECMAScript binding. Then when acceptNode is called you end up at http://heycam.github.io/webidl/#es-user-objects step 1 substep 3, discover that IsCallable(O) is true, and set X to O. Then in step 1 substep 11 subsubstep 1 the [[Call]] of X is invoked, which calls the function in question. So in particular, in the case of comment 0 the filter will return FILTER_ACCEPT, and this is perfectly well specified by Web IDL as long as the DOM spec says to call the acceptNode method on the callback interface object.
In the same way as https://dom.spec.whatwg.org/#concept-event-listener-invoke I guess. (I wish bug 25138 and especially bug 17713 were fixed already.)
https://github.com/whatwg/dom/commit/c8ef4c9079d2f585ec803c00a8ab97999ef2f4c4