Re: Deprecating DOMFocusIn/DOMFocusOut (was: DOMActivate vs. Click)

On Jul 22, 2009, at 5:11 PM, Jacob Rossi wrote:

>> 3) "DOMActivate" is slightly different from "click", because it  
>> won't fire for a click that is not an activation. I could imagine a  
>> contrived use case
>> where you set a "DOMActivate" handler at the root element to track  
>> all activations - "click" wouldn't work because you'd get a bunch  
>> of other clicks
>> as well. But I don't know of anyone actually doing this, so I am  
>> not sure if it is a compelling use case.
> To do this, one would want to use capture (to make sure another  
> listener didn't cancel the propagation). However, if you use capture  
> you still have no guarantee that the DOMActivate actually resulted  
> in an activation (another listener could call preventDefault() )--  
> so you're no better off. If I understand you correctly, that was the  
> intention of your proposed use case (detecting when an activation  
> actually happens as opposed to just random clicks).
> Furthermore, web apps are blurring the lines of what elements have  
> activation behaviors. Many sites today are providing "activation  
> behaviors" which are the result of click events that did not occur  
> on an element with an officially associated activation behavior.

I concede that my proposed use case is even weaker than I originally  
thought, for the reasons you stated.


Received on Thursday, 23 July 2009 00:13:31 UTC