W3C home > Mailing lists > Public > public-forms@w3.org > July 2009

Re: Deprecating DOMFocusIn/DOMFocusOut

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 22 Jul 2009 17:31:37 -0400
Message-ID: <4A678539.7040008@mit.edu>
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:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:51 UTC