> 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.
> 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.