W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

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

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 19 Aug 2009 21:16:06 -0700
Message-ID: <c9e12660908192116n471b4fb0h6f84cbd9c104b01f@mail.gmail.com>
To: Stewart Brodie <stewart.brodie@antplc.com>
Cc: www-dom@w3.org
On Thu, Jul 23, 2009 at 2:31 AM, Stewart
Brodie<stewart.brodie@antplc.com> wrote:
> 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.
>> >
>> > 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.
>>
>> 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.
>

I'm not going to comment on that at this time. However this:-

> Does that mean that for compatibility, I now need to raise focusin,
> DOMFocusIn *and* focus events?  I think that would mean I now need to raise
> 12 separate events just to transfer the focus from one node to another in a
> different document!
>
>
- is worth commenting on.

Focus is implemented in different browsers. We have:

IE onfocusin...bubbles
domfocusin.....bubbles
focus..........does not bubble

IE onfocusin seems to be implemented only in IE. I am not aware of
other browsers implementing that.

domfocusin is implemented in Opera, I know of.
focus is implemented everywhere.

Strategies for using delegated focus events:

+----------------+-----------------------------------+
| Implementation | Strategy                          |
+----------------+-----------------------------------+
| only "focus"   | a capturing event listener        |
| "domfocusin"   | a bubbling listener               |
| "focusin"      | a bubbling listener               |
+----------------+-----------------------------------+

So, if delegated bubbling is desired, the developer would first want
to know which event he can register. And since that is not possible, I
think it ought to be addressed.

A "hasEvent" feature and a less clunky "createEvent" method are
overdue. I am going to make a proposal for that. Coming soon.

Garrett
Received on Thursday, 20 August 2009 04:16:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT