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 WGsReceived on Tuesday, 15 September 2009 07:44:43 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:55 UTC