W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: Deprecating DOMFocusIn/DOMFocusOut

From: Jacob Rossi <rossi@gatech.edu>
Date: Tue, 15 Sep 2009 15:52:55 -0400
Message-ID: <b1dbfad70909151252j58f5309qe7485af63d8727d7@mail.gmail.com>
To: Olli@pettay.fi
Cc: Doug Schepers <schepers@w3.org>, mjs@apple.com, www-dom@w3.org
On Tue, Sep 15, 2009 at 1:47 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> On 9/15/09 8:25 PM, Jacob Rossi wrote:
>>>>
>>>> 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(). :-)
>>
>
> adding .relatedTarget to UIEvent would break backward compatibility, unless
> the new parameter for initUIEvent would be optional.
> Also, it would be a bit strange to have relatedTarget as the
> 7th parameter of initUIEvent, but 15th of initMouseEvent.
> (We can't change the order of initMouseEvent's parameters)
>
> I don't like initXXXEvent either, but since we have them, it is better
> to keep them working consistently.
>
>
> So mainly just because of this I'd add FocusEvent.
> It should probably extend UIEvent, although the traditional
> focus and blur events are just Events (in DOM 2 Events).
> Those events could be changed to be FocusEvents.
>
>
> -Olli
>

You make a good point. Adding FocusEvent probably is the best.  But is
it necessary to change focus/blur to also be FocusEvents? I understand
that it would be slightly awkward for them to not be the same. But
I'd be in favor of not changing them unless it provides some
additional needed functionality.

--Jacob
Received on Tuesday, 15 September 2009 19:53:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT