[whatwg] DOM-related and API-related feedback
mikewse at hotmail.com
Sun Dec 28 06:29:26 PST 2008
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
> > > 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?
More information about the whatwg