I realize that the select dropdown version of a listbox (or a combo-box if
you can edit it as well) has been around for a very very very long time.
Scroll-wheel mice now are at least 7 years old in mass-production so you
would think in that time the selectbox/combobox would have been changed to
have some new behaviors to match the needs of a the almost ubiquitous
(outside Mac) use of a scroll-wheel mouse.
What's the problem you might add. Well ... it has to do with the way a
combobox retains its focs after onChange. I realize it has to do this in a
world where you can use the keyboard to make a selection by typing ahead "U"
to get closer to "United States", for example. Or just using the arrow key
b/c you know your selection is not that far away. If we blurred onChange
that would be bad.
What is also bad is if you are a mouse user and you use a combobox, the
standard behavior that I have seen from new users especially on longish
forms is to open combobox (create focus) use scrollwheel to find selection
(NOT use the scrollbar itself and seldom use the keyboard); once found click
selection and then try to re-center the next field by using the
scroll-wheel. But what happens is that the page doesn't scroll b/c the focus
of the form is still on that combobox so the scrollwheel is changing the
selected value. This is VERY bad if the selectbox has an onChange function
of some kind.
Has anyone come up with a design to mitigate this issue? What would be an
ideal behavior for a list like this that doesn't support any metadata? Are
we forced to use "radio buttons" (single select) or "checkboxes"
(multiselect) in a scrollable widget of our own? Can this be done with the
"blind" type ahead function when you are working with a list of 200 options
like a country list or a date selector?