Re: Deprecating DOMFocusIn/DOMFocusOut

On Wed, Jul 22, 2009 at 10:46 PM, Jacob Rossi<t-jacobr@microsoft.com> wrote:
> Yes, so in response to that action, here's how IE handles focus events:
>

In response to what action?

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

Too bad that that is not what actually happens in IE.

Should it?

For example, the P element can be made focusable in many browsers by
giving it a tabindex. If the p is focused, and there is an enter
keypress, does onclick fire?

Here is what HTML 5 has to say about it:
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#focus

I only skimmed, but saw:

"The tabindex  content attribute specifies whether the element is focusable"...

and

"This means that an element that is only focusable because of its
tabindex attribute will fire a click event in response to a non-mouse
activation (e.g. hitting the "enter" key while the element is
focused)."

That sounds idealistic. Something Opera might do.

--------------------------------------------------
Tab to the P and hit enter.

Result:
IE 7, IE 8, Firefox 3.5.1, Safari 4.0.2:
  onclick does not fire.

Opera 9.6.4
  " [p clicked] " (onclick fired)

<p id='p' tabindex="0" onclick="this.firstChild.data += ' [p clicked] ';"
onfocus="this.firstChild.data += ' [p focused] ' ;">
p has onclick and tabindex
</p>
<button onclick="this.firstChild.data += ' [button clicked] '
;">button </button>
</p>
----------------------------------------------------

[snip explanation]

Garrett

> --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 06:27:37 UTC