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:

-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 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:16 UTC