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

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

From: Charles McCathieNevile <chaals@opera.com>
Date: Thu, 23 Jul 2009 00:18:55 +0200
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
To: "Doug Schepers" <schepers@w3.org>, "Anne van Kesteren" <annevk@opera.com>, "wai-xtech@w3.org" <wai-xtech@w3.org>
Message-ID: <op.uxhplte8wxe0ny@pc162.lan028.oslo.opera.com>
IMHO, and cc'ing the WAI-xtech list to see if PF really agrees with me.

On Wed, 22 Jul 2009 23:05:25 +0200, Doug Schepers <schepers@w3.org> wrote:

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

They were created at a time when there were serious accessibility problems
activating the relevant events through keyboard use, and it was a
compromise between fixing the more common events and doing nothing - in
that sense it was indeed political.

Since then, the original events have in fact been improved in browsers,
and the reason for retaining these is back-compat (this was an early
decision of the old WebAPI WG) at the request of other groups.

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

I think it makes good sense to deprecate them, pointing out that people
shouldn't keep using them but should use the improved originals. (And it
only took ten years to get to this :) ).

Likewise, the click event is now cross-platform and device-independent, so  
the reason for a seperate DOMActivate is gone, and that should also be  
deprecated.

I haven't looked carefully at the impact on WCAG 2 yet, but the impact on  
WCAG 1.0 is that the relevant checkpoints 6.4 [1] and 9.3 especially, but  
also some others need not be updated. However the techniques documents  
should note that it is possible to use the focusin/out and click events  
because they are generally device-independent in this way (mouseover,  
mousein/out by contrast are still problematic). If someone could check  
this for WCAG2 it would be helpful.

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

[1]  
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-keyboard-operable-scripts
[2]  
http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-device-independent-events

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
       je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Wednesday, 22 July 2009 22:19:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT