- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 22 Jul 2009 17:31:37 -0400
- To: Doug Schepers <schepers@w3.org>
- CC: "www-dom@w3.org" <www-dom@w3.org>, public-forms@w3.org
Doug Schepers wrote:
> I have not deprecated DOMActivate, because it seems different enough
> from 'click' to me, and is widely referenced enough that I think it
> should be retained (though it has a terrible name). Firefox has
> implemented it, so I'd be curious to here them respond to Maciej's
> claims that it breaks existing Web content.
Maciej's claim is that firing DOMActivate but not click on keyboard
activation breaks existing web content.
This claim looks correct to me, with my Gecko implementor hat on.
For example, in Gecko, for links (<html:a href="something">):
1) The default action of a mouse click on a link is to fire an
activate event at that link.
2) The default action of an activate event on an anchor is to trigger
the link.
3) The default action of a keypress for the "return" key on a link
is to fire a click event at that link.
Similarly for radios and checkboxes keypress events for "space" or
"enter" fire a click on that checkbox or radio, for radios
left/right/up/down arrow keypresses fire a click on the new radio button
to focus, enter in a textfield fires a click on the submit button for
the form, and so forth, or inputs of type button/reset/image/submit the
"enter" and "space" keys fire a click event (on press for enter and
keyup for space), and so forth.
In fact, the fact that there's a separate DOMActivate is quite a bit of
a hassle (esp. because for some cases canceling the DOMActivate needs to
cancel the click too, if I read the code right).
-Boris
Received on Wednesday, 22 July 2009 21:32:22 UTC