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

Differences in each of the focus-related events, as I understand them:

focus (as in DOM L2 Events): fires on an element after it has received focus. Does not bubble. Is not cancelable. Only applies to form elements.
focus (as currently in DOM L3 Events): same as in DOM L2 Events except can now be applied  to any focusable event target, not just form controls.
focusin (as implemented in IE): fires on an element right before it is about to receive focus. Bubbles. Is not cancelable.
DOMFocusIn (as in DOM L2 Events): same as focus in DOM L2 Events except can be applied to any focusable event target, not just form controls AND it bubbles.

blur (as in DOM L2 Events): fires on an element after it has lost focus. Does not bubble. Is not cancelable. Only applies to form elements.
blur (as currently in DOM L3 Events): same as in DOM L2 Events except can now be applied  to any focusable event target, not just form controls.
focusout (as implemented in IE): fires on an element right before it loses focus. Bubbles. Is not cancelable.
DOMFocusOut (as in DOM L2 Events): ): same as blur in DOM L2 Events except can be applied to any focusable event target, not just form controls AND it bubbles.

In IE, focusin and focusout are identical to DOM L2 Event's DOMFocusIn and DOMFocusOut except that they fire prior to the focus change occurring.

--Jacob



-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com]
Sent: Wednesday, July 22, 2009 6:27 PM
To: Jon Gunderson
Cc: Charles McCathieNevile; Doug Schepers; Anne van Kesteren; wai-xtech@w3.org; Jacob Rossi; Travis Leithead; www-dom@w3.org; public-forms@w3.org
Subject: Re: Deprecating DOMFocusIn/DOMFocusOut (was: DOMActivate vs. Click)


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 02:11:06 UTC