On Jul 21, 2010, at 5:24 PM, Ojan Vafai 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.
You mention activeElementId, but there must be other side effects that matter.
It's a bit gross, but 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
This sequence doesn’t sound too terrible to me. But I don’t fully understand the proposal. At the time the focusin event fires we won’t yet know what item is getting focus? Is the design that the focusin event’s target knows it will be getting focused? What about focus changes that come about along with selection changes? Or is there no such thing? Sounds like some differences are: 1) The blur event in Opera and IE will see the new focused node as the active element, but in WebKit and Firefox will see no active element at all. 2) Same for DOMFocusOut, but IE and Firefox are not affected. Is there a good reason to do blur the Firefox way instead of the Opera/IE way? Maybe because it’s the legacy WebKit way, and hence likely to be depended on by WebKit-tested or WebKit/Firefox-tested content? -- Darin