[wp-trac] [WordPress Trac] #31696: Better select, multi-select, and autocomplete/suggestion inputs in the admin (was: Select2 integration in core)
noreply at wordpress.org
Sun Mar 22 12:09:33 UTC 2015
#31696: Better select, multi-select, and autocomplete/suggestion inputs in the
Reporter: section214 | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Future Release
Component: | Version: 4.1
Administration | Resolution:
Keywords: | administration
Changes (by helen):
* keywords: has-patch =>
* version: trunk => 4.1
* milestone: Awaiting Review => Future Release
Going to reframe this ticket a little bit to look at the problem instead
of the solution, since it's new. Long select lists are difficult to use,
particularly on mobile, and multiple select is even worse on desktop.
Short of changing the browsers themselves, we should try to provide a
better experience for our users.
I am in favor of making those better in specific places in the admin,
which then plugin/theme authors could utilize. Originally, we were
considering choosing a library alongside bigger work on #19867 and #9864,
but I think at this point we've done enough background research on
existing libraries to introduce one now for existing use cases, and
continue working on those other tickets assuming a given implementation.
Here is a summary of past discussions and thoughts:
* Conceptually, suggestions and selections are quite different, and we
don't always do this well in core. In multisite, where jQuery UI
Autocomplete is currently in place, we abuse it a little bit to handle
scaling concerns and it ends up doing both. The admin email address for a
new site suggests possible existing user emails but still allows arbitrary
input, which is correct behavior, but so does adding an existing user to a
site, which by definition should not accept arbitrary input. The former
would be an example of suggestion, while the latter is an example of
selection as enabled by autocomplete. Ideally, a solution here could
handle both cases with appropriate UI for each, as well as things like
multi-select and tag-type input.
* Given the feature set that we need and the details of licensing, we are
essentially left with one choice in the current landscape:
[https://select2.github.io/ Select2], which in v2 (in RC as of this
writing) has been entirely re-licensed under MIT. Two other libraries were
looked at in some detail - [http://harvesthq.github.io/chosen/ Chosen],
which has a fairly limited feature set, and
[http://brianreavis.github.io/selectize.js/ Selectize], which is not
license-compatible. Creating and maintaining our own solution is not a
* Given experiences in the past with external JS libraries and changes
that break back-compat, as well as the potential need to someday change
libraries or otherwise make some larger underlying change, we need to
create our own JS wrapper with instantiation.
* Anything we adopt needs thorough vetting, particularly in terms of
mobile/touch handling and varying accessibility methods. The last time I
checked Select2 v2, keyboard accessibility was not the most pleasant
experience. This may mean upstream contributions, which is great. I have
found the maintainers to be friendly, reasonable, and responsive.
* Places that would be served better include: timezone dropdown, pages
dropdown (with #9864 for scaling issues that we could address using Ajax
searching), users dropdown (#19867 for those scaling issues), and tags
/non-hierarchical taxonomy input. Each of these flexes different features:
option groups, templating (so that hierarchy can be displayed in some
fashion), and tag-style input, respectively. We should start with the
simplest case and then iterate from there.
* We should look at implementing testing for every portion we can, whether
that's QUnit or otherwise.
I wonder if all of this could be done within a plugin right now, rather
than iterating on monster patches which can be quite frustrating and leave
untracked files lying around. We were able to do this within
[https://github.com/helenhousandi/wp-19867-9864 a testing plugin], so I
imagine it can be done targeting specific items, with a test page for a
possible more generic class-based magic instantiation case.
Specific to the proposed patch/approach, and as general advice: class
names should be semantic and not tied to the technical implementation, so
something like `.wp-select` would be preferable to `.select2`. I am not
completely sure we should implement this in the end; my instinct is that
this should still be chosen deliberately and with thought put into the
options to be set, as I am not convinced that all select elements need to
be replaced across the board. I would be interested in thoughts on whether
it would be inconsistent and confusing to users to keep some native select
elements alongside enhanced UI, as well as all of the rest of the above.
Ticket URL: <https://core.trac.wordpress.org/ticket/31696#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac