- From: Doug Schepers <schepers@w3.org>
- Date: Tue, 15 Sep 2009 03:44:31 -0400
- To: www-dom@w3.org
Hi, Maciej- Thanks for the quick reply. Maciej Stachowiak wrote (on 9/15/09 3:17 AM): > > On Sep 14, 2009, at 11:21 PM, Doug Schepers wrote: > >> I did adapt focusin and focusout to the existing DOM event interfaces >> a little: rather than add the orginal (and useful) IE 'toElement' and >> 'fromElement' properties, I mapped them to to the 'target' and >> 'currentTarget' properties, respectively. > > Instead of 'currentTarget', I'd suggest adding the 'relatedTarget' > attribute from mouse events to focus events. 'target' and > 'currentTarget' already have well-defined and useful meanings for all > events, so I don't think we should change the meaning of these for focus > events. I considered that, but it would also require a change to either the Event or UIEvent interface, and I didn't think that was necessary... 'currentTarget' actually describes it pretty well, since focusin happens before the focus shift, and it there doesn't seem to be a current value for 'currentTarget' on focusin or focusout events. Note that I did not change the behavior of focus, blur, DOMFocusIn, or DOMFocusOut events... they all still have identical values for 'target' and 'currentTarget', which was pretty consistent in my tests (though I didn't test IE). Also, I forgot to link to the spec draft itself, so that might make it clearer. [1] Anyway, that was my reasoning, but I'm don't feel strongly about it. If other folks think that we should add 'relatedTarget' to Event or UIEvent instead, I'm content to do so. [1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-uievent-event-order Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Tuesday, 15 September 2009 07:44:43 UTC