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
>