Nice! Thanks for sharing - with HN as with anything it's as much chance and timing as anything else as to whether a post gets up-voted or sinks unnoticed. </meta>
If I click on one of these and select something then the next time I click it just flickers instead of opening. I think they have something wrong with their event handlers.
I had some trouble viewing data members that were longer than the select box, they would wrap down to a second line and overlap the next entry. I also could not use the mouse to scroll through the list and using the up and down arrows was sluggish. I am dealing with a very large list, but the original chosen seems to handle it pretty well.
Sorry but this experience is badly broken in iOS and highlights yet again why native controls are always preferable over custom controls for compatibility. Also, don't forget about enabling accessibility by using ARIA.
Should these sorts of widgets be the default implementation of those types of controls in desktop browsers? As long as they can be done with the same input information, this sort of input seems like a "user preference" issue.
Yeah, that's why you do it on the client-side. If the widget doesn't work on an iPad then an iPad browser shouldn't default those controls to that widget. A desktop browser could, though Nobody would be worse off, and nobody would be the wiser (except the user).
And if in Backbone you'd like to have it preselect the value, run something like this after render (so you don't have to add much logic to your handlebar template for the markup):
@$("#address_country_field option").each ->
$(@).attr "selected", "selected" if self.model.get("address_country") is $(@).val()
It'd be nice to see some folks share their menu styles. The gradient on the select doesn't quite fit in with all site styles.
In Firebug, you can ask the :hover state to stay active.
1. HTML tab
2. Click on the element
3. Style menu on the right panel
4. choose :hover
It tricks the browser into thinking the mouse is really over the element (i.e., it doesn't just add :hover), so if you have a hover class added via JS that should work too.
(Apparently this feature has been there for a long time, but I only found it recently. Changed my Firebug life.)
Chosen.js has a great UI, but I found it challenging to do customizations to the library. I wish that the authors of the library had exposed more event hooks or built it with more modularity.
We used Chosen in an Australian news site which targeted South East Asia and Pacific island nations. 4 of the 11 language streams on the site relied on @font-face embedded fonts to provide support for displaying East Asian languages (Khmer, Burmese, etc).
Chosen helped us overcome a fairly major multi-browser issue where embedded fonts weren't being used inside <select> elements (oddly it seemed to work in IE6 but not IE7). Since Chosen transmutes the <option>s into style-able divs, this allowed us to use our @font-face fonts with very few issues. We ended up using it across the site for consistency (with a few exceptions) and all in all I think it provided a usability improvement for most of our users.
I've been using this a lot in our projects. It would be really a killer for selects with thousands of items. But it really kills the performance at least with Firefox. For small country selects it's still fine.
> Instead of forcing your users to scroll through a giant list of items, they can just start typing the name of the item they were looking for.
Who's forcing? Modern browsers allow a user to type (in lowercase) text to find in a select element while focused and will scroll to an exact match inside of it. It would require some instructions, but deviations of that behavior have been around for a while.
> Because chosen replaces normal html select fields, you don't need to do anything special to make it work for browsers without JavaScript.
One definitely needs to do "something special" to make them work. Limiting options to massively bloated libraries like jQuery and Prototype is a big problem, especially for graceful degradation (impossible with both).
I'd be interested in something that works without a DOM library (definitely not impossible). Support beyond IE 8 would be a great idea as well.
I don't think 'massively bloated' is a fair way to describe either jQuery or Prototype. Both of these libraries offer a lot. A better way to say it would be 'picked up some weight recently'.
That being said, I agree that this would be better off without jQuery; when every millisecond, every kilobyte matters, jQuery is simply off the table.
I agree with you that 'massively bloated' is a huge overstatement, and this plugin is clearly intended for desktop-style apps as an improvement to the default desktop-browser's select element. In desktop-land the 32kb it takes to download jQuery (min+gz) is absolutely nothing, and easily overshadowed by a single image file.
Perspective: My company has a jQuery/jQueryUI single-page web app (with MVC underpinnings) which serves a number of commercial customers very successfully. Does it matter that the whole app (which includes this plugin) may take 2-10 seconds to load from a cold-cache? No. After that there is absolutely zero load time throughout the entire app.
Btw, we also don't care about oldIE because we can insist commercial customers install Chrome-frame, which they are generally happy to do. They'd much rather that than we push a new 'native' desktop app at them and require them to install a .NET or Java runtime.
I wish people moaning about bloat and browser-support would actually think about the developers out there building products for very really use-cases that don't match their own mythical high-expectations of 'zero footprint/works-everywhere'. Some of us just want to get work done for paying clients and plugins like this are absolute life-savers.
> Modern browsers allow a user to type (in lowercase) text to find in a select element while focused and will scroll to an exact match inside of it.
Additionally they always highlight item that begins with typed letter. Because of that in default combobox i can type only "po" to get Poland, whereas search after typing "po" highlights French Polynesia. I think that difference is worth noting because it may searchbox more or less useful depending on data.
I'll agree with others that it isn't the easiest thing in the world to customize. Here's a hacky approach I threw together under time pressure to reshade it for dark sites, for example:
What I prefer to this is https://github.com/JamieAppleseed/selectToAutocomplete, because of the fuzzy matching. For example, I can type US or UAE, and it will select United States and United Arab Emirates respectively. But both of these are a great step in getting rid of unwieldy and uselessly long lists.
We've been using it for some time now, but it renders differently across different browsers with subtle alignment and padding issues. In the end, we just disabled it on anything less than IE8 and not one of the major web rendering engines. But it's pretty.
This is a great piece of software in terms of presentation and ease of use. However, it can make your life difficulty if you want to do anything outside of the scope that the authors intended. It's very difficult to build dynamic UIs with chosen select boxes because there's zero documentation of the code itself, which is what you'll be modifying if you want to do anything advanced. The devs did a good job building a select box, but a bad job making it extensible and documenting it.
Overall, I'd recommend it if your needs are simple, but you might be better off rolling your own or using another library if you need anything advanced.
I agree with the consensus that this is a nifty control. That being said, I have had major performance problems when using it with a large set of items in the choice list. Any more than a couple hundred, and it's gonna chug.
As awesome as they may be, they break the default Mobile Safari view for forms. Related to this, I ask honestly, why or why not should element design and usability be a responsibility of browser vendors?
On my iPhone (and most other mobile browsers I'd assume), the default controls beat Chosen's controls every time. There's a reason control implementation is left to the browser. If you do use Chosen, be careful to disable it on mobile.
It works exactly like it does in the browser, meaning, on iOS/Android it doesn't toggle the default OS action for select boxes. A real bummer considering it looks great.
This looks a lot like 99lime.com's HTMLkickstart. The js & html for 99Lime's "Select.fancy multiple" is really similar (if not identical) to Chosen's plugin. Did Harvest build 99Lime?
Really wanted to use this on a recent project, but found the appearance to be too inflexible. Would really like the ability to adjust the height of the element easily.
He probably means newer browsers’ rendering for the HTML5 <input type="number">. Spinners are the little up/down arrows next to number fields that increment/decrement the number. More info: http://www.html5tutorial.info/html5-number.php
I'm also using this and would like to point out that by default chosen does its instant search using "begins with"-type semantics. To get chosen to do the search using "contains"-type semantics you have to activate a little switch like this:
.chosen({search_contains: true});
which isn't immediately obvious from the docs (I had to sift through their issues on github to discover this).
The only thing I find missing is that, with the keyboard on a multiple select box, I can't remove my 1st choice without having to remove my 2nd choice too. (So, for instance if I choose Polar Bear and also choose Brown Bear, I try to move my cursor between them in order to Backspace over Polar Bear but I can't. I have to Backspace over Brown Bear + Polar Bear in order to delete Polar Bear.) It would be nice if, when I used my direction keys, it would highlight the selected items individually and then let me hit Delete or Backspace on my keyboard to delete just that one.
There appears to be several pull requests related to keyboard controls. I haven't looked into any of them in depth but one of them may solve the issues you are talking about.
If you use Chrome or Safari on MacOS 10.8, they uses the new mini-scrollbar in the browser. Removing those old-fashioned scrollbars dramatically improves the look of web UI's.
(Tried to submit it as a story the other day but zero upvotes.)