I don't get what the difference between this and Chosen.js is? Can someone explain?
Select2 - A better way to make select boxes (with jQuery)
51–60 of 60 posts
Re: Select2 - A better way to make select boxes (with jQuery)
#52Is 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.
Re: Select2 - A better way to make select boxes (with jQuery)
#53Earlier quoted context omitted.
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...
Re: Select2 - A better way to make select boxes (with jQuery)
#54It 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.
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.
Re: Select2 - A better way to make select boxes (with jQuery)
#55Earlier quoted context omitted.
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.
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.
Re: Select2 - A better way to make select boxes (with jQuery)
#56Earlier quoted context omitted.
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.
Re: Select2 - A better way to make select boxes (with jQuery)
#57Earlier quoted context omitted.
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.
Re: Select2 - A better way to make select boxes (with jQuery)
#58Earlier quoted context omitted.
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).
Re: Select2 - A better way to make select boxes (with jQuery)
#59Earlier quoted context omitted.
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.
Re: Select2 - A better way to make select boxes (with jQuery)
#60Earlier quoted context omitted.
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 tr…
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.