RE: Deprecating DOMFocusIn/DOMFocusOut

Yes, so in response to that action, here's how IE handles focus events:

focus, blur, focusin, and focusout can be registered on any element which is "focusable."

During a focus change from elementA to elementB, the following events are fired in this order:

1. focusout:   srcElement is elementA, toElement is elementB, bubbles, not cancelable
2. focusin:  srcElement is elementB, fromElement is elementA, bubbles, not cancelable
3. Focus changes from elementA to elementB
4. blur: srcElement is elementA, does not bubble, not cancelable
5. focus: srcElement is elementB, does not bubble, not cancelable

In regards to the spec, toElement and fromElement are probably best spec'd as a single property (relatedTarget). They are also not set if the focus is going to or coming from something not on the page (another window, tab, browser frame, etc.).


--Jacob

________________________________________
From: Doug Schepers [schepers@w3.org]
Sent: Wednesday, July 22, 2009 8:06 PM
To: Anne van Kesteren
Cc: Jacob Rossi; Maciej Stachowiak; Travis Leithead; www-dom@w3.org; public-forms@w3.org
Subject: Re: Deprecating DOMFocusIn/DOMFocusOut

Hi, Anne-

Anne van Kesteren wrote (on 7/22/09 6:12 PM):
> On Wed, 22 Jul 2009 23:05:25 +0200, Doug Schepers<schepers@w3.org>
> wrote:
>> 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.
>
> There are no focusin and focusout events. At least, I believe last I
> checked onfocusin in SVG mapped to an existing focus event. If
> anything we should use focus and blur.

As I said, I added focusin and focusout events in the same draft as I
deprecated DOMFocusIn and DOMFocusOut, because focusin and focusout are
supported by IE.  I chose to deprecate DOMFocusIn and DOMFocusOut in
favor of focusin and focusout because they both bubble, unlike focus and
blur.

However, there may be other differences between DOMFocusIn/DOMFocusOut
and focusin/focusout, such as when they fire in relation to focus and
blur.  Olli and Jacob have taken actions to clarify that for us.

So, the issue is not completely resolved, but I'll leave the draft the
way it is until we know more.  I also want to hear from other working
groups (including Forms, WAI, and SVG) before we finalize on a decision.


>> I have not deprecated DOMActivate, because it seems different
>> enough from 'click' to me,
>
> How is it different? As far as I know they are identical in
> function.

No, as Maciej said (twice), DOMActivate is essentially a subset of click
that is only fired when something is activated.


>> and is widely referenced enough that I think it should be retained
>> (though it has a terrible name).  Firefox has implemented it, so
>> I'd be curious to here them respond to Maciej's claims that it
>> breaks existing Web content.
>
> That was not the claim.

I wrote this email in a rush (the D3E telcon was starting), and didn't
state that as clearly as I could have; I didn't mean it to sound
controversial.  However, Boris understood what I meant and responded to
my satisfaction.


> Also, what does deprecation mean here?

That existing implementations that support DOMFocusIn and DOMFocusOut
should continue to do so, to support existing content that uses them,
but that all implementation should use the replacement events instead.
Unless they have a market need, implementations that don't already
support deprecated events should not support them in future versions.

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

Received on Thursday, 23 July 2009 05:47:17 UTC