W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

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

From: Doug Schepers <schepers@w3.org>
Date: Wed, 22 Jul 2009 17:05:25 -0400
Message-ID: <4A677F15.2020004@w3.org>
To: Anne van Kesteren <annevk@opera.com>
CC: Jacob Rossi <t-jacobr@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Travis Leithead <travil@microsoft.com>, "www-dom@w3.org" <www-dom@w3.org>, public-forms@w3.org
Hi, Anne-


Anne van Kesteren wrote (on 7/22/09 9:35 AM):
> On Tue, 21 Jul 2009 23:16:14 +0200, Jacob Rossi<t-jacobr@microsoft.com> wrote:
>> Ok. That makes sense. Given that, is DOMActivate simply left in DOM
>> L3 Events to support backwards compatibility with DOM L2 events? Or
>> are there still use cases which it solves that other events do
>> not?
> I think the sole reason we have DOMFocusIn, DOMFocusOut, and
> DOMActivate is political. I'm not sure if that changed to backwards
> compatibility at this point, but I doubt it.
> DOMFocusIn and DOMFocusOut have been retained on request of the Forms
> WG and for DOMActivate I do not really remember. Fact of the matter
> is that focus/blur/click work fine and already are platform
> independent and much better understood by authors of Web
> applications.
> I'd be very happy if could consider yet again dropping
> DOMFocusIn/DOMFocusOut/DOMActivate.

Taking a look at the current state of implementation [1], and seeing the 
similarity of function between IE's focusin/focusout and 
DOMFocusIn/DOMFocusOut, I have now included focusin/focusout, and 
deprecated DOMFocusIn/DOMFocusOut in favor of those event types.  This 
is a tentative decision, but it seems logical to me; any comments are 

I urge the Forms WG to take note of this, and update your future specs 

Maciej Stachowiak wrote (on 7/21/09 5:13 PM):
> Unfortunately, Web compatibility requires sending a "click" event for
> non-mouse-driven activations. In particular, it is a common practice to
> give an <a> element or an <input type="button"> element an onclick
> attribute and the page author expects it to trigger even for keyboard
> activation. This practice precedes the existence of the DOMActivate
> event and remains common. Authors almost never use a DOMActivate handler
> instead.

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.

[1] http://www.quirksmode.org/dom/events/index.html

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Wednesday, 22 July 2009 21:05:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:55 UTC