[webkit-dev] focusin/focusout events

Ryosuke Niwa rniwa at webkit.org
Mon Jul 26 00:55:24 PDT 2010

On Wed, Jul 21, 2010 at 5:24 PM, Ojan Vafai <ojan at chromium.org> wrote:
>  Opera 10.6: blur, domfocusout, focus, domfocusin
> Moves activeElement immediately before firing any events.
> WebKit nightly: blur, (dom)focusout, focus, (dom)focusin
> Clears activeElement before blur/focusout, sets active element before
> focus/focusin
> FF 3.6:blur, focus
> Clears activeElement before blur, sets active element before focus.
> IE 8: focusout, focusin, blur, focus
> Moves activeElement immediately before firing any events.
> It's a bit gross,

I agree. Very inconsistent.

> The only solution I can think of is to fire the following events in WebKit
> (in this order):
> focusout
> focusin
> {remove focus and clear selection as appropriate}
> blur
> domfocusout
> {add focus to new node and set selection as appropriate}
> focus
> domfocusin

That's the exact sequence defined by the spec, right? IMHO, conforming to
the spec is always a good thing unless the spec itself is wrong /

I'd like to say we could get rid of DOMFocusOut/DOMFocusIn or blur/focus,
> but I expect too many sites would break.

I wouldn't push that either for the backward compatibility.

I care more about meeting the use-case listed above than matching the spec.
> If we can meet the above use-case differently, I expect we could get the
> spec modified.

I'd really like to conform to the spec especially because all UAs are
inconsistent now. If we conform to the spec, we can justify any
backward compatibility issues caused by the change and start nagging other
vendors to fix their browsers instead.

Ryosuke Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100726/2481a426/attachment.html>

More information about the webkit-dev mailing list