I think the order as specced at http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-focusevent-event-order is fine. It seems to solve the ordering from a backwards compatibility case.
The spec leaves out when document.activeElement is changed though. erik On Mon, Jul 26, 2010 at 18:32, Ojan Vafai <[email protected]> wrote: > There are a few concerns on the table: > 1. We don't match the DOM3 spec. I'm not too worried about this. Neither > does anyone else. We could probably get the spec to change if noone is going > to implement it as is. > 2. We don't match other browsers. It's not clear to me what changes are > worth making here. > 3. There's no way to get the selection *before* an element is blurred. > The third one is the only one I really care about solving, in the short term > anyways. I'd like there to be a blur-like event that we fire *before* > clearing the selection. With our current ordering of events, that would mean > clearing the selection after the blur event or the focusout event or both, > which no browser does. That said, it might be safe to just change this. > Since no browser has a selection during the blur event and only IE has one > during focusout, we might be able to get away with just changing that as > noone should be depending on the selection at that point. Perhaps that's > worth trying? > On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler <[email protected]> wrote: >> >> You mention activeElementId, but there must be other side effects that >> matter. > > The only other side effects I can think of are the focus outline (which > could probably be tested via getComputedStyle?) and clearing the selection. > In non-IE the selection isn't cleared if focus is moving across frames. But > when focus moves within the same document, you get the following: > IE 8: The selection is cleared after the focusout event and before focusin, > blur, focus. > WebKit && Opera: It's cleared before any events are fired. > FF 3.6: It's cleared before any events are fired unless focus is moving to a > textarea/input (not contentEditable!). > >> >> > 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? > > 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. > >> >> 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. > > 3) IE fires focusout before the selection is cleared if the element being > focused is the body (e.g. click from a contentEditable onto a non-focusable > element). >> >> 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? > > My only concern was backwards compatibility, but I have no evidence that it > is or isn't a valid concern. > Ojan _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
