- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 14 Jun 2011 23:59:44 -0700
- To: David Flanagan <dflanagan@mozilla.com>, public-script-coord@w3.org
On Tue, Jun 14, 2011 at 10:45 PM, Cameron McCormack <cam@mcc.id.au> wrote: >> Are there any specs currently using [Callback] for interfaces that >> exist as both host objects and native JavaScript implementations? > > I don’t know how well it is implemented, but there is XPathNSResolver, > which both can be supplied from script and can be returned from a > createNSResolver call: > > http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathNSResolver > http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathEvaluator-createNSResolver It's implemented in Firefox >> Are there any specs that define [Callback] interfaces that have >> constants? > > None come to mind. NodeFilter http://www.w3.org/TR/DOM-Level-2-Traversal-Range/traversal.html#Traversal-NodeFilter >> If not, it sure would be simpler to say that the [Callback] >> attribute implies the [NoInterfaceObject] attribute. > > It would indeed. I am concerned there might be some valid use cases for > having an interface that can be implemented by both user script and the > implementation, but even so this would be uncommon. > > In this kind of situation I might think to flip the extended attribute – > have a [RequireInterfaceObject] to override [Callback]’s default > behaviour of inhibiting the interface object. Works for me. / Jonas
Received on Wednesday, 15 June 2011 07:00:50 UTC