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.

Received on Tuesday, 15 September 2009 19:53:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:36:55 UTC