Re: Removing 'caller' from WebIDL

(Adding in Maciej, since he might have an opinion)

On Sep 4, 2011, at 1:52 PM, Brendan Eich wrote:

> On Sep 1, 2011, at 9:50 AM, Brendan Eich wrote:
>> On Sep 1, 2011, at 12:49 AM, Anne van Kesteren wrote:
>>> On Thu, 01 Sep 2011 08:11:09 +0200, Brendan Eich <> wrote:
>>>> What can be done to remove the caller uses other than document.all from HTML's spec?
>>> The simplest approach is having nobody implement it / remove support for it. The specification is there to reflect reality and vice versa.
>> Will Opera remove caller from its collections other than document.all?
>> If I recall correctly, Oliver has been in on the discussions about deprecating caller in the past. Cc'ing him to check on odds of WebKit removing caller from the non-.all collections.
> Hi Sam, this thread is about removing caller from WebKit's HTML collections other than document.all.
> Gecko doesn't support calling any collections other than document.all. We don't see interop problems. But they could exist. Would you be willing to try removing caller in nightlies and see how that goes? That might start the ball rolling.
> Right now we have a circular reasoning (if you can call it reasoning) situation where the HTML spec uses caller for collections that are not callable in Gecko, and when I asked for the spec to remove caller from these collections' IDL, Anne and Hixie suggested that the browsers that *do* support caller should drop it first. I then asked Anne if Opera would -- no answer yet -- and Oliver suggested I try you. I hope with your help, we can end this Mexican stand-off.
> My opinion is that the spec should drop caller anyway, since Gecko does not implement it and I know of no content that detects or version-sniffs to use callable collections in non-IE branches of JS control flow. But what do I know?
> /be

Hi Brendan,

It is relatively easy for us to run that experiment, and I have no problem doing it, but I am not sure it will give us enough data to remove it, since we have quite a bit of content that is singly coded to WebKit (e.g. Dashboard and iOS specific content).  (I filed and attached a patch to make the change so that we can remove engineering effort from the equation.) 

Just to be clear, the only reason to drop caller on collections is that it cannot be implemented in javascript? But that would continue to be the case with document.all?  I am honestly not sure I understand the benefit of dropping it, especially since 3 out of 4 engines support it.  If the main issue is dropping support in WebIDL, so that proliferation of the property doesn't continue, I think reduced proliferation can be achieved by moving it to a section of the spec that clearly marks it as for legacy use only, as I think we have discussed in the past. 

I should also note, that in WebKit, we allow plugins to make the HTMLObjectElement (as well as HTMLEmbedElement) callable via NPAPI, though that may be outside the scope of this issue. 


Received on Sunday, 4 September 2011 21:45:08 UTC