scrolling usability problems

[acornejo]

There are two usability problems when scrolling.

1. Unless you are actively scrolling, there is no indicator that shows if there are more items above/below (arrows would be nice).
2. If you scroll hard, the select box go to the last item (which is expected) and the entire page scrolls down (unexpected, and undesirable).

Great work btw, I stumbled this looking for alternatives to select2 and chosen.

Alex

[adamschwartz]

Thanks for the feedback, Alex.

1. A scrollbar should be visible unless the user is using an Apple device with touch. For this situation, I agree we should probably add some CSS scrollbars with ::webkit-scrollbar.
2. Yeah, this stinks. We'll have to bind to the mousewheel event and I believe either preventDefault or stopPropagation (or both) when we detect we're at the top or bottom. One potential downside to this approach is that I believe the scrollTop checks will trigger a repaint, partially taxing scroll performance.

[acornejo]

I think you are right with point (1) Adam, I tested it on OS X using chrome.

Regarding point (2), I think there might be an easier solution by simply tweaking the overflow property of the CSS, or is there a reason why you think this wouldn't work (I haven't actually looked at your css/html/js, so perhaps there is an obvious reason why this won't cut it).

Otherwise, if you think that would be an acceptable solution, I wouldn't mind taking a stab at a pull request.

[acornejo]

I went ahead and created pull request #5 with the fix.

As a sidenote, I noticed the gh-pages branch is using a completely different version of select.js... so it was a bit tricky to test my patch.

Also I would suggest adding the procedure that builds the markdown files to html into the grunt file.