[whatwg] Focus management
mikewse at hotmail.com
Thu Jun 12 04:28:45 PDT 2008
Ian Hickson wrote:
> window.focus() isn't in HTML5 as there doesn't appear to be a
> valid use case for it and it is too abusable, and thus
> shouldn't be supported. If pages depend on it being supported
> we could make it a no-op, I guess.
I would think the opposite. Being able to pop a browser window
to front is quite useful, and I have used it f ex in notifier
windows that sit in some kind of loop checking for a condition
(possibly minimized) and "pop up to front" when there is new
data. And I wouldn't want to use alert() in these cases.
Then maybe this functionality really should have another
function name, popToFront() or something, but I don't think
there is enough reason to change it.
> Focusing an element inside a window should raise the window
> or hidden tab at the UA's discretion.
I think the opposite about this one too, I guess it shows how
different web users may think about their visual experience ;-)
Popping a window to front on every programmatic element focusing
would make windows pop to front more often than needed. Windows
should be forced to front as little as possible as this is
messing with the user's desktop experience. Also regard users
that don't use the standard Windows focus model (click to focus
= focused window on top) but rather the "X-mouse"-model (focus
follows mouse = focused window may be partially obscured). If
they are typing data into a partially obscured browser window
that then calls elem.focus() to move keyboard focus, they will
get an undesired window raise.
So, I think it is desired to distinguish between element keyboard
focus and window raising, and only let the latter be done
explicitly and not as a side-effect of doing the former.
Lastly, I guess if deprecating window.focus() devs would start
using myDummyElem.focus() instead, to achieve the same result?
More information about the whatwg