[whatwg] DOM-related and API-related feedback

[Ian Hickson]

On Sun, 28 Dec 2008, Mike Wilson wrote:
> Ian Hickson wrote on 28 december 2008 12:38:
> > On Thu, 12 Jun 2008, Mike Wilson wrote:
> > > 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.
> > 
> > As a user, I would find such behavior incredibly annoying.
> 
> I think you need to think about not only alien pages that want
> to do you harm, but also about web applications f ex on 
> intranets that solve a complex task through the use of multiple
> windows.

Right, that's the ones that are really annoying.


> I've had users of the latter demand that we (the developers) raise 
> windows automatically based on different events.

Stop using different windows. :-)


> > I've now specced window.focus() and window.blur(), but mostly as 
> > no-ops.
> >
> > I've noted that window.focus() could trigger a notification.
> 
> I read your updated text, and while it is great that you have added the 
> notification stuff, I think removing focus's current behaviour is a hard 
> legacy to break. Even "good" scripts would need to workaround it at 
> times.

A "good" script by definition wouldn't use a popup window and so wouldn't 
have to raise it. However, the current text doesn't preclude the behavior 
of legacy user agents if that behavior is desired by the UA implementor, 
so there's no need to say more in the spec as far as I can tell.


> I think UAs could be encouraged to handle focus like many popup blockers 
> do; have a global setting to determine the default behaviour (system 
> focus|notification|ignore) and then being able to override this setting 
> for f ex selected sites or the current session.

Doing so would be conforming, but I don't see why we should encourage it.


> > > > Focusing an element inside a window should raise the window or 
> > > > hidden tab at the UA's discretion.
> > > 
> > > 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.
> > 
> > I don't see any reason to let the latter be done at all really.
> 
> I'm confused. I responded to this sentence in your previous mail:
> 
>   "Focusing an element inside a window should raise the 
>    window or hidden tab at the UA's discretion."
> 
> but now you say that this should never be done (which I think is fine 
> btw). What did I misinterpret?

Nothing, as far as I can tell. The spec allows the behavior you describe, 
but doesn't require it. It's up to the UA implementor what happens.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'