- From: Jacob Rossi <rossi@gatech.edu>
- Date: Tue, 15 Sep 2009 13:25:09 -0400
- To: Doug Schepers <schepers@w3.org>, mjs@apple.com
- Cc: www-dom@w3.org
>> 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. I have to disagree. I don't think currentTarget is a good descripter of this element. That would be very inconsistant with its meaning in any other event's dispatch: "From the perspective of an event listener this shall be the event target the listener has been registered on. " The to and from elements are not necessarily even a part of the event flow propagation path (much less, the target on which the listener registered). We should keep this definition consistant. I agree with Maciej that relatedTarget makes more sense. I'd be in favor of adding it to UIEvent rather than make a FocusEvent simply because I'd rather not have yet another set of init_____Event() and init____EventNS(). :-) --Jacob
Received on Tuesday, 15 September 2009 17:26:16 UTC