[whatwg] DOM-related and API-related feedback

[Mike Wilson]

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. I've had users of the latter demand that we (the
developers) raise windows automatically based on different
events. Personally I'm not a fan of auto-raising windows (f ex
MS Windows does it too often for my taste) but I think these
users' use cases have been valid.

> 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.

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.

> > > 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.
> 
> 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?

Best regards
Mike Wilson