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

?To add my own piece of content to the discussion, I
must say (as a web developer) that when I needed to
write some event handling on both IE and Standards
Model, I often asked meself why the standards model
was so complex (and so long to type).

window.attachEvent("onload", fx);
vs
window.addEventListener("load", fx, false/true);

It took my months to understand why there was a 3rth
parameter in the stds mode and I must say I was
setting it to true or false nearly at random, changing
when the behavior was not what I expected.

Now that I understand clearly his meaning, it doesn't
prevent me from thinking it should be marked as
optional since tuning the 'capture' settings is not an
usual process in Web page devlopement (when you're
making Web apps it's another story, but the point is
that when you build web apps, you're generally smart
about DOM).

Regards,
François

-----Message d'origine----- 
From: Olli Pettay
Sent: Monday, October 04, 2010 4:36 PM
To: Garrett Smith
Cc: www-dom@w3.org
Subject: Re: [DOM Level 3 Events] optionality of the capture argument in 
addEventListener/removeEventListener

On 10/04/2010 08:31 AM, Garrett Smith wrote:
> On 10/3/10, Olli Pettay<Olli.Pettay@helsinki.fi>  wrote:
>> On 10/01/2010 08:20 PM, Ojan Vafai wrote:
>>> On Wed, Sep 29, 2010 at 8:31 PM, Jonas Sicking<jonas@sicking.cc>  wrote:
>>>
>>>      On Wed, Sep 29, 2010 at 10:04 AM, Olli Pettay
>>>      <Olli.Pettay@helsinki.fi<mailto:Olli.Pettay@helsinki.fi>>  wrote:
>>>       >  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.
>>>
>>>      I don't think requiring the last argument is helping a whole lot 
>>> with
>>>      that right now. I've heard multiple times developers say:
>>>
>>>      "I don't know why I have to specify the last 'false' value, but I 
>>> have
>>>      to do that everywhere when I call addEventListener".
>>>
>>>
>>> In addition to this, I've seen many developers toggle the boolean value
>>> because it happened to fix a specific bug without understanding why (and
>>> it usually caused other bugs). Forcing people to use the boolean is not
>>> synonymous with forcing them to understand it.
>>>
>
> You can expect that that unskilled developers, given a badly designed
> API and not enough time to learn on the job, will do just that.
>
> Have ever I mentioned how much I love boolean parameters?
>
>>> Ojan
>>
>> But effectively removing the parameter means that even
>> fewer web developers understand DOM propagation model in the future,
>> I believe.
>>
> Read carefully. The proposal was to make the useCapture parameter
> optional; not to remove it.
I said "effectively removing", and I mean that people would just
not use the the last parameter and possibly quickly
forget that there is such thing and even fewer developers
would actually know how event propagation works.
And yet the event propagation model is quite useful when
used properly.


-Olli


>
> How much did the useCapture parameter being mandatory do much to help
> developers understand its implications? If they're fiddling with
> toggling it back and forth to fix a bug without understanding why
> they're doing that, wouldn't it be perfectly fair to say that there is
> no evidence that the useCapture parameter helped developer
> understanding?
>
> The capture phase is confusing and representing it with a boolean
> argument doesn't help that.
>
> Making the useCapture parameter optional will not reduce understanding
> of the capture phase.
>
> Garrett
>

Received on Monday, 4 October 2010 15:34:38 UTC