W3C home > Mailing lists > Public > public-forms@w3.org > July 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-

+public-forms@w3.org

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 
welcome.

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


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

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

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