On Tue, Jul 27, 2010 at 10:37 AM, Darin Adler
<darin@apple.com> wrote:
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?
I think we do know this and it wouldn't be too hard to implement. It's just a question of what we think the best behavior is. Specifically, in Document::setFocusedNode, we know both the new focused node and the old focused node when firing these events.
The “we” I meant is the JavaScript code on the webpage.
I see. I hadn't thought about this part. As per the current state of the DOM 3 spec for the target/relatedTarget event object:
|
|
target |
relatedTarget |
|
blur/DOMFocusOut |
element losing focus |
element losing focus |
|
focus/DOMFocusIn |
element receiving focus |
element receiving focus |
|
focusin |
element receiving focus |
element losing focus |
|
focusout |
element losing focus |
element receiving focus |
The spec looks reasonable to me and I think we could implement it without worry about web compatibility since we would only be modifying the focusin/focusout events, which we just added recently. The only thing I'd like to change in the spec is that focusin/focusout are not cancelable, but that's a whole separate issue and something that should be addressed on www-dom first.