W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2011

Re: Implementation requirements for [Callback] interfaces

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 14 Jun 2011 23:59:44 -0700
Message-ID: <BANLkTi=aSW3Mi6dRougf9JHWha_N8S7g5g@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC