W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2010

Re: [DOM Level 3 Events] optionality of the capture argument in addEventListener/removeEventListener

From: Ben Lerner <blerner@cs.washington.edu>
Date: Fri, 24 Sep 2010 14:04:51 -0700
Message-ID: <4C9D1273.1040906@cs.washington.edu>
To: Jonas Sicking <jonas@sicking.cc>
CC: Sergey Ilinsky <sergey@ilinsky.com>, www-dom@w3.org
undefined, which converts to boolean false.  So as long as saying 
2-argument addEventListener/removeEventListener behaves like a 
3-argument call with false (i.e., applicable to bubbling-phase), it 
should be easy enough and just fall out from the JS calling 
conventions.  The question is whether the WebIDL for these functions is 
to be read as "there must be three arguments for the call to be legal", 
or whether it can be read as "implementations will use the following 
parameters".  As related evidence (though I don't know which way it 
argues!) consider that only window.open and Image() constructors and a 
few other functions deal with multiple arities of the functions, but 1) 
the IDL explicitly mentions the arity, and 2) the behaviors of the 
variants are (almost always) the same as calling the highest-arity 
version with 'undefined' for the missing arguments.  (The only 
exception, I think, is window.open.)

~ben

On 9/24/2010 1:48 PM, Jonas Sicking wrote:
> On Fri, Sep 24, 2010 at 12:17 PM, Sergey Ilinsky<sergey@ilinsky.com>  wrote:
>> There are modern browsers that made 3rd argument in the
>> addEventListener/removeEventListener be optional. Is this a legal step?
>> If I understand correctly, specification requires 3rd argument to be passed,
>> thus the new behaviour not backed by the change
>> in specification only destabilizes web as a platform.
>> Personally, I like the behaviour, but cannot use it as long as not every
>> browser does that.
> Currently it does not appear to be legal based on my reading of the
> latest editor drafts. However I would love to change that. It wouldn't
> be a big change in the spec, just stick [optional] in front of the
> useCapture argument, and it should be no problem as far as backwards
> compatibility goes. And at least in gecko it would be trivial to
> implement.
>
> The only problem I can think of is that it means that people might
> write pages that only works in newer browsers, however that is true
> for any new feature added.
>
> / Jonas
>
>
>
Received on Saturday, 25 September 2010 09:15:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:05 GMT