Re: [D3E] focusin/focusout

Hi Doug,

On Sep 15, 2009, at 12:44 AM, Doug Schepers wrote:

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

I think it's really important to retain this definition of  
currentTarget:

"Used to indicate the EventTarget whose EventListeners are currently  
being processed. This is particularly useful during the capture and  
bubbling phases. When used with the Event dispatch and DOM event flow,  
this attribute contains the target node or a target ancestor."

If anyone writes completely generic event management code based on  
this, they will be in for a nasty surprise if focusin and focusout  
events changes the semantic. I think incompatibly changing the meaning  
of an existing Event property is worse than adding a new attribute or  
new interface.

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

I'd suggest either:

(a) Add relatedTarget to UIEvent (removing it from MouseEvent to move  
it up) or
(b) Add a FocusEvent interface inheriting from UIEvent which adds a  
relatedTarget

Note that relatedTarget serves the exact same role for mouse hover  
events as it would for focus events, so it's a very logical choice,  
and would be much less confusing than changing the behavior of  
currentTarget.

I welcome input from others on this.

Regards,
Maciej

Received on Tuesday, 15 September 2009 07:58:34 UTC