- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 07 Apr 2010 21:41:22 -0400
- 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 UTC