W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2010

Re: UIEvents should provide relatedTarget property

From: Doug Schepers <schepers@w3.org>
Date: Wed, 07 Apr 2010 21:41:22 -0400
Message-ID: <4BBD3442.5040007@w3.org>
To: Axel Dahmen <brille1@hotmail.com>
CC: www-dom@w3.org
Hi, Axel-

Thanks for your comment.  We have introduced a new FocusEvent interface 
for just this purpose:
 
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-focusevent

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


Axel Dahmen wrote (on 4/7/10 8:04 PM):
> There are scenarios when it's important to know which element is gaining
> focus. Currently it's impossible to find out which element is going to
> get the focus within a blur() or focusout() event handler.
>
> Thus, I suggest to add a "EventTarget relatedTarget" property to the
> UIEvent class...
>
> a) pointing to the element which gains focus within blur() and
> focusout() events,
>
> b) pointing to the element which has lost focus within focus() and
> focusin() events.
>
>
>
> Moreover, an event sequence policy should be defined, stating the
> focus() will immediately follow blur() and focusin() will immediately
> follow focusout().
>
> Currently, Google Chrome and Apple Safari enqueue focusin() *after*
> focusout() has returned. This causes other events to intercept these two
> events (e.g. a call to setTimeout(..., 0). This should not be possible.
>
>
> Calling element.focus() within a blur() event handler should update the
> target for the enqueued focus() event but not re-enqueue the focus()
> event. Same for focusin()/focusout().
>
>
> Axel Dahmen
> www.axeldahmen.de
>
>
>
Received on Thursday, 8 April 2010 01:41:25 GMT

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