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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 22 Jul 2009 18:26:41 -0700
Cc: Charles McCathieNevile <chaals@opera.com>, Doug Schepers <schepers@w3.org>, Anne van Kesteren <annevk@opera.com>, wai-xtech@w3.org, Jacob Rossi <t-jacobr@microsoft.com>, Travis Leithead <travil@microsoft.com>, www-dom@w3.org, public-forms@w3.org
Message-id: <5136898A-2157-44B8-953A-5097FE091F2C@apple.com>
To: Jon Gunderson <jongund@illinois.edu>

On Jul 22, 2009, at 5:55 PM, Jon Gunderson wrote:

> These event handlers are commonly used to create styling effects for  
> node or more importantly related nodes that cannot be styled using  
> CSS selectors.
>
> If an element receives keyboard focus what event can be used to  
> update visual styling?

The "focus" and "blur" events can be used for this. "DOMFocusIn" and  
"DOMFocusOut" largely duplicate their functionality. Although for  
purely visual styling, I would recommend CSS :hover effects over script.

> If we don't need focusin and focusout, then I assume mouseover and  
> mouseout will also be deprecated.
>
> Focus styling is not very well implemented in browsers or by web  
> developers.

No one is proposing taking away focus events. The question is just  
whether we need to have two separate sets of them.

  - Maciej

>
> Jon
>
>
> ---- Original message ----
>> Date: Thu, 23 Jul 2009 00:18:55 +0200
>> From: "Charles McCathieNevile" <chaals@opera.com>
>> Subject: Re: Deprecating DOMFocusIn/DOMFocusOut  (was: DOMActivate  
>> vs. Click)
>> To: "Doug Schepers" <schepers@w3.org>, "Anne van Kesteren" <annevk@opera.com 
>> >, "wai-xtech@w3.org" <wai-xtech@w3.org>
>> 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
>>
>> 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
>>
> Jon Gunderson, Ph.D.
> Coordinator Information Technology Accessibility
> Disability Resources and Educational Services
>
> Rehabilitation Education Center
> Room 86
> 1207 S. Oak Street
> Champaign, Illinois 61820
>
> Voice: (217) 244-5870
>
> WWW: http://www.cita.uiuc.edu/
> WWW: https://netfiles.uiuc.edu/jongund/www/
>
> ---------------------------------------------------------------
> Privacy Information
> ---------------------------------------------------------------
> This email (including attachments) is covered by the Electronic  
> Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and  
> may be legally privileged. It is intended for the use of the  
> individual or entity to which it is addressed and may contain  
> information that is privileged, confidential, and exempt from  
> disclosure under applicable law. If the reader of this email is not  
> the intended recipient, or agent responsible for delivering or  
> copying of this communication, you are hereby notified that any  
> retention, dissemination, distribution, or copying of this  
> communication is strictly prohibited. If you have received this  
> communication in error, please reply to the sender that you have  
> received the message in error, then delete it. Thank you.
>
>
Received on Thursday, 23 July 2009 01:27:23 UTC

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