While it's always good to have people exploring improvements to UI elements, it would be superior to have those improvements show up as patches to WebKit or Firefox or GNOME or whatever else. Native UI elements need the improvements; that's where UI actually belongs.
On mobile in particular, there's a couple of problems with the web-page approach to UI. One, it adds yet more stuff to download that "shouldn't" be necessary just for a page to be functional. And two, if the interface is too desktop-like I bet it'll either behave badly or not work at all on an iPhone (there's a reason iOS' scroller-menu-thing looks nothing like the Mac's pop-up menu interface despite both using Cocoa). Theoretically the second problem could be addressed by code that detects the device type and presents yet another web interface for mobile, but that'll probably make the first problem of page bloat even worse.
In what way does the W3C block browsers from changing the UI of form controls? Most interesting innovation happens outside of the standard's committees, and as long as it is standardized in a reasonable amount of time, that's ok.
This is outside the scope of the W3C, and within the scope of browser vendors. The HTML specification doesn't say how a select element should be rendered, just that it should allow the user to choose from a list of options. That browsers all render select elements roughly the same is convention, not specification, and browser vendors could change if they wanted to.
Yes, vendors shouldn't do whatever they want, they should stick to the spec. In this case, the spec allows any rendering for select elements which allows the user to choose from a list of options. Using a different rendering from other browser does not violate the spec.
I've always felt like this was a major shortcoming of the specification. Inputs should have some consistent visual specification along with support for a well-defined set of styling options. We go through all of these gyrations precisely because the spec. doesn't define standard behavior. The differences in color, size, and shape from platform to platform (and browser to browser) can be very problematic for anyone trying to make the web beautiful.
The other side of the argument is that it is beneficial that browsers determine how such elements work. If they did not, millions of mobile users would be struggling with tiny but beautifully rendered UI elements.
It breaks normal usage. Tab to a normal Select, press 'n' 3 times and you get New Hampshire (the 3rd item starting with 'n'). Tab to Select2 press 'n' 3 times and you get nothing.
Maintaining compatibility with existing keyboard UI should be considered essential for accessibility. And I haven't bothered to check compatibility with ARIA.
True but this also supports dynamically loaded data with infinite scrolling and other things that a normal select can't do. I suppose it's a trade off.
Hey, twitter did it with Bootstrap. Javascript is the assembly of the internet so lets get busy re-inventing and then breaking every wheel known to man.
In Firefox on OS X most of the Select2 inputs don't seem to be in the tab order at all, they get skipped over. If I do have one selected and type "new" I expect to see "new hampshire" (or something else starting with new), but it drops the first character, opens the drop down and I have "ew" in the text field.
Except people expect select lists to work like that. This is nicely done, but it breaks a number of established conventions about how select lists work.
It got type ahead support (like in Google search field), ability to define your own filtering algorithm and robust event system which gives the flexibility to modify almost any aspect of the behaviour.
I was just about to ask this question, but there seems to be some differences: loading of remote data (I believe in chosen you have to hook yourself the ajax part), the infinite scrolling is also a good idea, and the drag & drop sort was missing.
Chosen doesn't support adding tags dynamically. It also looks like select2's api is more friendly and convenient. I will be converting my chosen dialog to select2 as it looks like an improvement overall.
I chose select2 for homehelpnow.com.au because of paged ajax lookups. Check out the place search box on homehelpnow.com.au. Its AU-based, so might be a bit slower for you US folk.
Feature request (I might add it to the github issues later, but I don't have time right now to do it justice):
I almost never, ever use a mouse (MacBook Pro's trackpad is the best pointing device I've ever encountered), but when I do, I usually select thing with ONE click of the mouse, instead of two (I'm lazy). For example, if I want to select 'Print...' under 'File' menu, I I move the cursor to the 'File' menu, hold left (or right, if I want to use something off a contextual menu) mouse button down, move the cursor down and over 'Print...' and let go of it. It's much faster I think, and I'm used to it. It's useful specially when you have to right click on something and then select an item with the left button.
The old, naïve `select`s all behave as expected (as they're usually native UI elements), but this `select2 ` thing does not work like this.
Tangential, but ever since browsers started to implement the behavior: if a select is selected and start typing, it automatically starts matching options, I don't mind them as much. It's a feature for power users and there are definitely cases where it doesn't apply (e.g. you don't know the options), but it's a big usability win.
Also, for what this is doing, I think comparing it to a <select> is wrong. It's so much more powerful and really shines (and is worth 50k of JS) in situations where you couldn't even use a <select>.
It completely failed for me on Android browsers - although I admit I gave up after a few minutes. I tried the examples (http://ivaynberg.github.com/select2/#) on the latest native android browser, Chrome mobile, and Opera mobile.
Is it only me or anybody else finds the multi select annoying and not at all good UX? It looks good but the means to select many values is inefficient and tiresome.
And since when the only use for select multiple is tagging?
The problem occurs when there are few options, not virtually unlimited options and especially if they are not known in advance. Then discoverability suffers and also forces you to type three times instead of just mark them.
or at least newest. As someone who has tried to integrate Bootstrap into the UI of an existing product I'd say only helps if you don't have a designer. The number of bugs and the amount of code you end up having to deal with isn't worth it in the cases where a native element would have performed better.
Looking forward to trying the ajax stuff out even though the demo isn't working for me. I've been working with chosen on my current project which works fantastic and the dev is super responsive but I had to make my own control for large, server filtered lists and it looks and feels awful :)
Just added this to the CMS I'm building, as a quick-and-dirty way to let users select images. ActiveAdmin was listing every image name and the user had asked for a way to filter the list. Voila!
It's annoying that Select2 and Chosen don't create a 'close menu' transparent overlay over the rest of the page, so the menu closes if you click outside of it.
A click event would be triggered after the mouseup event, and you to open the dropdown on mousedown event so that you can do all the selection in one click.
I just tried binding .open() to the mousedown event and .close() to the mouseup event and it seems to work for that use case, but it still has to know to behave in the other way (open on mousedown, but don't always close on mouseup).
Oh right... I somehow forgot that pulldown menus can be used as their name implies, by clicking and holding down the mouse to open the menu, and release to make your selection; I've gotten so used to clicking to open, having them stay open, and then clicking again to make my selection (at least since Apple first enabled that feature in System 7). All of a sudden, I'm much less proud of my home-rolled pulldown-menu implementation I've been using.
Maybe it's just me, but I tend to dislike loading 50kb (plus the CSS file) scripts into my applications unless the service is built around something that said script adds a ton of value for.
I dunno, is 50kb relevant any longer? Still seems like the 50kb to 100kb range matters when adding in js files. At 5kb to 10kb I don't think much about it.
On mobile in particular, there's a couple of problems with the web-page approach to UI. One, it adds yet more stuff to download that "shouldn't" be necessary just for a page to be functional. And two, if the interface is too desktop-like I bet it'll either behave badly or not work at all on an iPhone (there's a reason iOS' scroller-menu-thing looks nothing like the Mac's pop-up menu interface despite both using Cocoa). Theoretically the second problem could be addressed by code that detects the device type and presents yet another web interface for mobile, but that'll probably make the first problem of page bloat even worse.