- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 22 Jul 2009 17:12:48 -0700
- To: Jacob Rossi <t-jacobr@microsoft.com>
- Cc: Charles McCathieNevile <chaals@opera.com>, Doug Schepers <schepers@w3.org>, Anne van Kesteren <annevk@opera.com>, "wai-xtech@w3.org" <wai-xtech@w3.org>, Travis Leithead <travil@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>, "public-forms@w3.org" <public-forms@w3.org>
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. Regards, Maciej
Received on Thursday, 23 July 2009 00:13:35 UTC