Re: Implementation requirements for [Callback] interfaces

On 6/14/11 11:59 PM, Jonas Sicking wrote:
> On Tue, Jun 14, 2011 at 10:45 PM, Cameron McCormack<>  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:
> It's implemented in Firefox
>>> Are there any specs that define [Callback] interfaces that have
>>> constants?
>> None come to mind.
> 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
So NodeFilter needs an interface object to define constants on, and 
XPathNSResolver needs an interface object and a prototype object because 
there might actually be host objects that inherit from the prototype.  
Should WebIDL require implementations to define NodeFilter.prototype?  
And if so, that presumably means that the DOM Traversal spec needs to 
specify the default behavior of NodeFilter.prototype.acceptNode() and 
similarly for any other spec that defines a [Callback] interface.  
(Unless, WebIDL specifies that these dummy methods do nothing and return 
undefined, but that then violates their signature).


Received on Wednesday, 15 June 2011 17:57:36 UTC