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

Maciej,

Thank you for the clarification, I then have no objection.

If there are changes being made to the DOM spec, I hope the working group will consider a means to enumerate what event handlers are associated with a DOM node.

This is a feature that is critical for evaluation tools looking at accessibility to check whether a HTML element may be interactive with users and needs to be described using ARIA markup.

Jon




---- Original message ----
>Date: Wed, 22 Jul 2009 18:26:41 -0700
>From: Maciej Stachowiak <mjs@apple.com>  
>Subject: Re: Deprecating DOMFocusIn/DOMFocusOut  (was:  DOMActivate vs. Click)  
>To: Jon Gunderson <jongund@illinois.edu>
>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
>
>
>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.
>>
>>
>
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 Friday, 24 July 2009 18:30:57 UTC