On Fri, 2007-04-20 at 11:52 -0400, Eben Eliason wrote: > > > Absolutely. Ideal behaviors: > > > > > > 1) The scrolling region directly visible beneath the mouse gets grab > > > focus. > > > 2) If two scrolling regions overlap, the top one should take the grab > > > focus. > > > 3) If a scrolling region is embedded in another (such as an iframe in > > > a web page), then the innermost region should get grab focus, unless > > > it reaches its min or max scroll and can no longer move, at which > > > point the next region in the hierarchy gets it. > > > > > > > Hmm I'm not convinced about this. Usually keyboard actions apply either > > globally (to the system or to the active window) or to the focused > > element. I feel pretty strange, interaction wise, to have a keyboard > > button depend on the position of the mouse. > > The grab key isn't so much a keyboard action as it is a modifier key > for the trackpad/mouse. This is very much like the behavior of a > scroll-wheel mouse (or Apple's two-finger scrolling), which always > scrolls the view beneath the cursor.
Well, yeah, but the fact that's physically part of the the keyboard doesn't really suggest it's a mouse modifier. And the fact that we have a scrolling mode (press/release) doesn't suggest it either. Btw what are the advantages of a scrolling mode/modifier over Apple's two-finger? > Requiring focus in the region won't work that well for several > reasons. First, it could require a click to set focus. Additionally, > it might be the case that every portion of the scrollable region is > clickable (eg. a long list where each row is clickable/selectable), in > which case the click intended to focus the region would actually have > an immediate unintended action. > I was thinking to use keyboard focus only in the case of multiple views. That's not optimal either admittedly. Marco _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
