[wp-trac] [WordPress Trac] #31696: Better select, multi-select, and autocomplete/suggestion inputs in the admin (was: Select2 integration in core)

[WordPress Trac]

#31696: Better select, multi-select, and autocomplete/suggestion inputs in the
admin
-------------------------+-------------------------------------------------
 Reporter:  section214   |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:               |     Version:  4.1
  Administration         |  Resolution:
 Severity:  normal       |     Focuses:  ui, accessibility, javascript,
 Keywords:               |  administration
-------------------------+-------------------------------------------------
Changes (by helen):

 * keywords:  has-patch =>
 * version:  trunk => 4.1
 * milestone:  Awaiting Review => Future Release


Comment:

 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
 great idea.
 * 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