Select2 - A better way to make select boxes (with jQuery) | Hacker News Reader

Select2 - A better way to make select boxes (with jQuery)

github.com

369 pointsbinarydreams57 comments

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.

Good points but I think you're preaching to the choir. The bottleneck is the W3C which is probably bogged with all sorts of red tape and politics.

That's why we have the WHATWG, whose mode of operation is much closer to the IETF's mantra of "rough consensus and running code".

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.

It's entirely within the scope of the W3C and IE6 is proof enough that vendors shouldn't implement things however they choose.

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.

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.

It also breaks two OSX defaults:

  - spacebar on a highlighted item should select it

  - the select menu should open on mousedown, not mouseup.

Otherwise, it's a very nice piece of work.

Maintaining compatibility with existing keyboard UI should be considered essential for accessibility. And I haven't bothered to check compatibility with ARIA.

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.

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.

Pressing a key 'n' times was a crutch for select boxes without a text filter. This is not needed here and doesn't even make sense.

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.

If you are on the look for a plugin with better auto-completion features, let me shamelessly pitch jQuery Smart AutoComplete - http://laktek.com/2011/03/03/introducing-jquery-smart-autoco....

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.

Here's the GitHub repo - https://github.com/laktek/jQuery-Smart-Auto-Complete

Obligatory: what's the difference between Select2 and Chosen? (http://news.ycombinator.com/item?id=4074501)

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.

Looks like it's based on Chosen.

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.

The biggest thing here is the AJAX loading of data. Like I said in that submission, Chosen really chokes if you have thousands of items in it.

Thousands of items arguably don't belong in a combobox, they should probably be split by letter, country, prefix, etc.

Yeah I mean imagine if say Google did something like that for their entire search results, how ridiculous would that be...

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.

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

A good example of select2 with paged ajax typeahead queries is the place search box at http://homehelpnow.com.au

Chosen can't do that.

Sorry, I meant infinite scroll not paged...

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.

I don't get what the difference between this and Chosen.js is? Can someone explain?

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.

Have you ever seen tagging done differently? It is the most compact and efficient way to add/delete tags.

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.

At the time jQuery widgets like this and Bootstrap CSS seems to be the best platform for frontend development.

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 :)

Page Up and Down keys don't work.

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!

Does this have the same constraints as Chosen does on iOS and Android?

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.

It closes when I click outside of it.

Ah, it does on the computer. On the iPad and iPhone, it does not for some reason.

It's a one line fix, just the developer listening for a mousedown and not a touchstart event.

https://github.com/ivaynberg/select2/issues/77

Ah, that'll do it. Listening for a click event should work for both, no?

A mouse is not a finger ;)

True, but they can both generate click events; I've got widgets that listen for clicks and work fine on mobile Safari.

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.

A coffeescript version would be really welcomed even if it is a pain in the ass to maintain two version of the same source code.

Demo broken in Chrome http://ivaynberg.github.com/select2/

Works fine in my Chrome!

And it has 'pragmatic control' :D

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.

Minified and served compressed it's 8.51k for the JS and CSS together.

I thought we were over thinking about file sizes on the disk. You should look at the gzip size.

Reply on news.ycombinator.com