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

Re: Focus (was: Deprecating DOMFocusIn/DOMFocusOut)

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Wed, 16 Sep 2009 22:04:24 -0700
Message-ID: <c9e12660909162204q54367a19nb7c87ac30de4b189@mail.gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: www-dom@w3.org
On Tue, Sep 15, 2009 at 1:02 PM, Doug Schepers <schepers@w3.org> wrote:
> Hi, Jacob-
>
> Jacob Rossi wrote (on 9/15/09 3:52 PM):
>>
>> On Tue, Sep 15, 2009 at 1:47 PM, Olli Pettay<Olli.Pettay@helsinki.fi>
>>  wrote:
>>>
>>>  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)
>

initUIEvent has 5 params, and initMouseEvent 15, so that would make it
the sixth parameter for initUIEvent and the 16th of initMouseEvent.

Would changing the method signature be backwards compatible? I think
it would not.

> ...
>>>
>>>  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.
>>
>> 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.
>
> I do see the functionality as needed... it provides the best way to
> intercept changes in focus before they happen, and to find both the "to" and
> "from" elements.
>
> In fact, it's worth thinking about changing focusin and focusout to be
> cancelable, to prevent the focus from changing.  I doubt there is any
> content that relies on them not being cancelable... what would people think
> of this idea?
>

Will a new "onfocusin"  break sites that use loose inferences?

What is the recommended practice for detecting this feature?

When introducing the new feature, have you considered:
  * How will the new feature will affect code in existing web pages?
  * How can the feature be detected?
  * What sort of fallback mechanisms are available?

Please do a google code search to see how it is used in existing web
pages. Please also see the delegating focus article on quirksmode.

Please do report back your findings.

Regards,

Garrett
Received on Thursday, 17 September 2009 05:05:04 GMT

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