This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15356 - NodeFilter callback
Summary: NodeFilter callback
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-28 15:47 UTC by Anne
Modified: 2011-12-29 12:30 UTC (History)
15 users (show)

See Also:

Attachments

Description Anne 2011-12-28 15:47:36 UTC 
I would like your help in figuring out how we should define NodeFilter per the latest Web IDL as implementations might have to change.

http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#nodefilter
http://dev.w3.org/2006/webapi/WebIDL/

The simplest I could come up with was to put all the constants on an exposed NodeFilter interface and put the acceptNode() method on a separate NodeFilterCallback callback interface.
Comment 1 Cameron McCormack 2011-12-28 23:59:42 UTC 
Or you could just write it as

  callback interface NodeFilter {
    const ...;
    ...
    unsigned short acceptNode(Node node);
  };

since callback interfaces that have constants on them do get an interface object (but not prototype property on there).

http://dev.w3.org/2006/webapi/WebIDL/#es-interfaces

The only problem with that is if you want to disallow { acceptNode: ... } being used as a NodeFilter.  If compatibility doesn't require it, then doing what you suggest would be OK.
Comment 2 Ms2ger 2011-12-29 12:24:10 UTC 
Why would we want to get rid of { acceptNode: ... }?
Comment 3 Anne 2011-12-29 12:30:53 UTC 
Ah, nice Cameron!

https://bitbucket.org/ms2ger/dom-core/changeset/1e5db6bdc60b