RE: Deprecating DOMFocusIn/DOMFocusOut

>Yes, the documentation is a bit wrong then...
Yes, I meant to mention MSDN is not accurate. I'll pass that along to them.

>But that's actually the behavior I would expect, from what I understood about focusout and focusin;
>they fire the event before the focus changes, giving the opportunity for interception, right?
That's the main purpose of focusin and focusout. It probably would have made more sense to name them beforefocus and beforeblur. But, what's done is done since there are likely a number of sites using these (I'll see if I can find some data to back that).

IMHO, w.r.t. DOM L2 Events, DOMFocusIn and DOMFocusOut were valuable because they could be applied to elements other than form elements and because they bubble. But browser implementations already allow focus/blur to be applied to elements other than form elements. So the only value-add of DOMFocusIn and DOMFocusOut is that they bubble

>From annevk: " What use case does bubbling enable that capturing does not?"

Well, not to get too far off topic here (the value of bubbling), bubbling (being the dual of capturing) allows you to have a listener on a parent node which is the default handler of focus changes within its children. However, you may want to provide a different functionality for just a subset of the children. So you attach listeners to those children which handle the focus change differently and then call stopPropagation().

Example, consider a form which has a number of different inputs. As the focus changes, you may wish to perform a different action based on whether the field was required or not. Rather than use capture phase and put your logic for deciding which behavior to perform in your handler, you can use bubbling. Put the listener on the form element which performs the default action for focus changes in your form. Then put different listeners on the input elements which are "required." Those listeners then stop the propagation of the bubbling.

But what one really wants (IMO), is to not only have a bubbling version of focus, but also to have it fire prior to the focus being changed. This enables even more use cases (since they provide the ability to intercept the change and perform an action before the focus actually moves). This is what focusin and focusout are in IE.

--Jacob

-----Original Message-----
From: Doug Schepers [mailto:schepers@w3.org]
Sent: Thursday, July 23, 2009 4:48 AM
To: www-dom@w3.org
Subject: Re: Deprecating DOMFocusIn/DOMFocusOut

Hi, Olli-

Olli Pettay wrote (on 7/23/09 7:24 AM):
> On 7/23/09 2:04 PM, Olli Pettay wrote:
>> focusout doesn't sound too useful
>> "[focusout ]Fires for the current element with focus immediately
>> after moving focus to another element. "
> Based on testing the documentation is wrong.
> http://mozilla.pettay.fi/moztests/focus.html

>
> when moving focus from 1st field to the second one IE dispatches
> focusout to the first one, then focusin to the second field, then blur
> to the first field and then focus to the second one.

Yes, the documentation is a bit wrong then... But that's actually the behavior I would expect, from what I understood about focusout and focusin; they fire the event before the focus changes, giving the opportunity for interception, right?

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Thursday, 23 July 2009 16:54:44 UTC