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

On 9/29/10, Doug Schepers <schepers@w3.org> wrote:
> 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.
>>

It is different here because a very common feature test is that of
existence inference, along the lines of:

if(document.addEventListener) {
  document.addEventListener("click", f, false);
}

And so if that is conceptually applied

if(document.addEventListener) {
  document.addEventListener("click", f);
}

- then it may work in newer implementations and will fail in some
existing implementations.

The amount of feature testing to be able to safely use the new feature
in the interim will make it not worth it. Clever manipulation of its
length property might work, but still easier for authors to not
feature test and just pass useCapture -- or not.

>> I don't support this kind of cnge.
>> 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'.
>
If the parameter is to be optional then `false` is a better default
value than true

And if you do this, I suggest adding an informative note to the
specification about the change (for authors).

Garrett

Received on Thursday, 30 September 2010 06:08:35 UTC