Re: Focus (was: Deprecating DOMFocusIn/DOMFocusOut)

Hi Doug,
> 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.

I think you misunderstood me. I definately think focusin and focusout
provide needed functionality. I was saying that we should leave focus
and blur to be Events unless switching them to FocusEvents (assuming
you make a FocusEvent type for focusin and focusout) provides more
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.

Could be useful. But also could be abused. I'm not sure I like the
idea of a script in a page being able to trap the focus. It will
definately need restrictions like not being cancelable if the focus is
lost to browser chrome or to another document view.

--Jacob



On Tue, Sep 15, 2009 at 4: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)
>
> ...
>>>
>>>  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?
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>

Received on Tuesday, 15 September 2009 20:18:44 UTC