Re: [D3E] focusin/focusout

Hi, Maciej-

Maciej Stachowiak wrote (on 9/15/09 3:57 AM):
> On Sep 15, 2009, at 12:44 AM, Doug Schepers wrote:
>> 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.

Excellent point.

>> 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 prefer option 1.  I agree that it's logical, and would make sense for 
authors already used to relatedTarget for mouse events.

> I welcome input from others on this.

I'll wait for input before making the change, but you've convinced me 
that this is a better solution.  Thanks.

-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Tuesday, 15 September 2009 08:25:41 UTC