W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2010

Re: [DOM3 Events] optional capture argument in add/removeEventListener [ISSUE-134]

From: Jacob Rossi <jrossi@microsoft.com>
Date: Thu, 28 Oct 2010 22:46:33 +0000
To: "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <D0BC8E77E79D9846B61A2432D1BA4EAE023D1312@TK5EX14MBXC116.redmond.corp.microsoft.com>
In regards to the question raised in the telecon about how to specify optional parameters using WebIDL, Travis pointed out to me that there isn't really a way to do this explicitly in WebIDL. However it can be accomplished by specing an overload for add/removeEventListener which lacks the useCapture argument. Then there would be text explaining that calling this overload is equivalent to calling the 3-argument add/removeEventListener method with useCapture set to false.


Hi, Olli-

Olli Pettay wrote (on 9/29/10 1:04 PM):
> On 09/24/2010 11:48 PM, Jonas Sicking wrote:
>> On Fri, Sep 24, 2010 at 12:17 PM, Sergey Ilinskywrote:
>>> 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.
> I don't support this kind of change.
> It happens way too often that people don't think about the phase, and
> that leads to bugs.

While I don't dismiss the merit of making methods logical and
consistent, and as pedagogical as possible, I think in this instance it
would be more intuitive and convenient to make the useCapture argument
optional for the majority of users.

I agree that understanding of the event propagation model is important
to developers, but I don't know how much the presence of a somewhat
anonymous boolean does to promote that knowledge.

If we change this, I'd assume the default value would be 'false'.

As Jonas says, any new feature won't work in older implementations
(without a script library shim), so I'm not overly concerned there.

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Thursday, 28 October 2010 22:47:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:16 UTC