[whatwg] Focus management

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?

Best regards
Mike Wilson

Received on Thursday, 12 June 2008 04:28:45 UTC