[META] [UX] Select2 / SelectWoo in core

[laryn]

Describe your issue or idea

There's been a number of comments over the years about adding a multi-select library to core to improve the UX in a variety of ways. I'll link the related issues below and provide a few pullquotes:

• [UX] Remove multi-select list form elements from core by switching to Select2 #1800 | [UX] Remove multi-select list form elements from core by switching to Select2
• Replace UI autocomplete with Select2 #459 | Replace UI autocomplete with Select2
• [UX] Change tags field display to use 'tag blocks' when entering tags #2121 | [UX] Change tags field display to use 'tag blocks' when entering tags

Other ideas and existing issues that reference select2:

• Abandoned (incomplete?) port of the Drupal Select2 module may provide a place to start via Replace UI autocomplete with Select2 #459 (comment) :
  https://github.com/backdrop-contrib/select2

• Comment from @jenlampton on [UX] Remove multi-select list form elements from core by switching to Select2 #1800 (comment) RE: the SelectWoo fork that may be better from an accessibility standpoint:

think I'm also leaning towards Select2 in terms of both features and aesthetic. As an added bonus, we could also use Select2 to replace our ancient autocomplete JS code. Here's an issue for Drupal about doing that very thing: https://www.drupal.org/node/2346973 That issue looks stalled due to front-end performance on the autocomplete, and accessibility. There appears to be some accessibility improvements in the SelectWoo fork.

• Comment from myself on Modules page tag filters [UX] Add "tags" to the modules page and in .info files #37 (comment)

(And as the select list of tags grows and becomes more unwieldy, hopefully it will turn into a select2 list allowing typing/autocomplete when/if select2 gets into core.)

• Comment by @serundeputy on [UX] move the clear log messages button to bottom of dblog messages page #2353 (comment) RE: 'Recent log messages' page filters

I think this improves the UX quite a bit, and we should hold off on the second bullet and address that UX issue when we get the select2 library in core

• Comment by @klonos on [UX] timezone drop-down should group timezones by continent #2928 (comment) RE: Timezone drop-down

(Triaged as possible accessibility issue on 08/17/2921. This one only seems to have come up because of possible accessibility issue with the suggested libraries, please add the [A11Y] tag if you think that this is an accessibility issue.)

[herbdool]

Looking at the repos it seems like select2 is being updated so perhaps it's now more accessible than it was. By "repos" I mean the JS libraries for select2 and selectwoo on github.

[klonos]

Between May 2018 when we started this issue and now, our Drupal brethren have taken the time to evaluate the various libraries out there (thank you for your efforts @bbenjamin ❤️ ). See all the "Evaluation" links in the issue summary at https://www.drupal.org/node/2346973

Although no specific library has been selected yet for long select lists + multi-select, for things like entity reference fields and paths they've chosen to replace jQuery autocomplete with https://leaverou.github.io/awesomplete (because jQuery UI is being deprecated). See this separate issue about that: https://www.drupal.org/project/drupal/issues/3076171 and the META/roadmap: https://www.drupal.org/project/drupal/issues/3089455

Executive summary:

• It was the only library reviewed to not have any glaring accessibility issues
• Unlike most candidates, the functionality is applied to the existing text field. Most of the other options require select elements or hide the text field and create pseudo-inputs from other elements, creating entirely new markup that could result in broken forms and frustrated contrib developers.
• Awesomplete is in the Joomla 4 alpha, which means another large project has vetted it and has interest in its continued support
• A review of its Github suggests that important issues actually get addressed

(in other words, it's easily the most accessible, least disruptive option chosen so far)

...interesting:

Based on the discussion about the (quite reasonable) interest in having the experience/markup changed as little as possible, there are two aspects of this new implementation that are technically different, but arguably improvements. I'd like feedback on whether these improvements should be removed to match the experience or if they're acceptable changes since they're pretty good ones.

• With jQueryUI autocomplete, with fields using the "tag" widget: Even if maximum cardinality was reached, the autocomplete would continue providing suggestions, and they could be added to the field -- but only the first {{cardinality}} would actually be saved. With the Awesomplete implementation, suggestions are not provided once the field has reached max cardinality.
• With jQueryUI autocomplete, it's possible to add the same reference multiple times in the same field, but only one instance is actually saved with the entity. In the Awesomplete implementation, suggestions will not include items that are already entered in the field.

If there's a need to keep things very consistent, suggestion-warts and all, these can be split into their own issues.

...even more interesting:

It may not be necessary to add Awesomplete at all because:

• Awesomplete does not offer any new features or fixes, it is just a replacement for the end-of-life jQueryUI autocomplete.
• The implementation of Awesomplete in Drupal core is customized to the point that very little of the library is actually used. It is very close to being a Drupal-core custom solution already.

A custom solution could be preferable because:

• It can be integrated in a way that leverages the splitbutton render element, which is currently in progress: https://www.drupal.org/project/drupal/issues/1899236
• It is so close to a custom solution already, the additional effort required to make it fully custom would be less than the long-term effort required to keep a dependency current.

🤷

[klonos]

...another interesting quote from @quicksketch back in 2015:

I just spent a day trying to upgrade the D7 Select2 module to support the new 4.0.0 version of the library. It really doesn't like working with input fields. Dropping support for (hidden) inputs is actually listed as a feature of the new version: https://select2.github.io/announcements-4.0.html#hidden-input

In trying to use it on input textfields, Select2 simply has no support whatsoever now. It actually tries to embed <option> tags inside of the textfield <input> element. The only hope we'd have is doing as Wim suggested and replace the textfields with select elements.

I don't know if this is going to be a suitable replacement for autocomplete text fields. A select list isn't going to be the right element when dealing with large lists, which is pretty much any situation we have autocomplete currently: author name, term tags, the search on api.drupal.org, etc.

The whole situation is disappointing. The "best" library for autocomplete basically doesn't want to deal with autocomplete and wants to focus exclusively on replacing select list elements. I suppose it shouldn't be too surprising, considering their past claims that autocomplete/type-ahead is outside the scope of their goals: select2/select2#17.

[klonos]

...and another one:

...We can convert the textfield to a select with JS, then run Select2 on the new select list field we just created. However, that means we're going to have to adopt a lot of custom code to deal with converting a textfield to a select list. You'd need to account for single/multiple values, parsing the input field, converting it to a select list with the entered options selected. Then run Select2 on the resulting new select field and load the results via AJAX like we had been doing before. Before the values are submitted to the server, you have to convert these values back into a input so it would all come in as a single value in POST. A select list will send multiple values as an array.

Rather than attempt to revert the select back to input, we'd probably find it easier to maintain the original input on the page, and update it as the select list is updated.

So in summary, to use Select2:

• PHP outputs a textfield onto the page.
• Hide the original textfield and create a select list "copy" of the field with JS
• Apply Select2 to the select list, load results via AJAX
• On value change, update the original textfield.
• On POST, the server gets the value from the original field. The select element we could leave with no name attribute, so it would be nothing but a client-side widget for manipulating the hidden field.

So basically we'd re-implement the functionality that was removed from Select2 to support hidden fields.

I don't know... it's possible but doesn't seem right.

[klonos]

Accessibility report from the WordPress folks: https://make.wordpress.org/accessibility/2015/09/07/accessibility-usertest-select2 ...end respective issue opened about it in the Select2 issue queue: select2/select2#3744 (still open since 2015, but there seems to be activity throughout the years)

[klonos]

So yeah, it pretty much seems that either Select2, or a custom solution based on https://react-select.com have the most support for use in long select lists. https://leaverou.github.io/awesomplete is considerably smaller and less complex, but that's because it intentionally does less (that's why it has been selected to specifically replace the jQuery autocomplete - nothing else):

Awesomplete has fewer features than the other candidates, which makes sense as most of them are designed to enhance select elements, not just be autocomplete. A quick scan of Select2 shows all sorts of nice features that simply aren't needed for autocomplete.

[jenlampton]

So the options are to choose one clunky library to replace everything, or lots of little ones to replace each individual thing? I'd vote for the latter: a small thing for autocomplete, and a small thing for select, and other things in other places where we use jQuery UI.

…

On Fri, Jul 31, 2020, 9:39 AM Gregory Netsas ***@***.***> wrote: So yeah, it pretty much seems that either Select2, or a custom solution based on https://react-select.com have the most support for use in long select lists. https://leaverou.github.io/awesomplete is considerably smaller and less complex, but that's because it intentionally does less (that's why it has been selected to specifically replace the jQuery autocomplete - nothing else): Awesomplete has fewer features than the other candidates, which makes sense as most of them are designed to enhance select elements, not just be autocomplete. A quick scan of Select2 shows all sorts of nice features that simply aren't needed for autocomplete. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3069 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADBERZ6MXAE6D42I3D7PFDR6LXURANCNFSM4E5VCGOA> .

[klonos]

Well yeah. It's just that the favorites for select already do what awesomplete does, so we'd have two libraries that accomplish the same thing. It does make sense for forms that only have an autocomplete (they will need to load only the small, autocomplete-specific library; so performance++); and the same goes for forms that only have a select. But on forms that have autocompletes as well as selects, we'd be loading both libraries, when the single select library would suffice 🤷

[bbenjamin]

Glad my multiselect research was helpful! One of the reasons for reconsidering Awesomplete is that much of the functionality it provides will be available in a new render element, Splitbutton, which is pretty close to getting in core . The most recent patch at the time I type this is here: https://www.drupal.org/project/drupal/issues/1899236#comment-13767381. It was originally intended to just be a dropbutton replacement, but we've been able to build it in a way that accommodates many different uses, as there are many use cases that require toggleable lists of items.

For example, Splitbuttons can function as a (fully accessible) select by simply adding a#title property to the render array. It should be possible to use Splitbutton as a foundation of an autocomplete widget, too. A partially implemented Splitbutton-autocomplete is part of Splitbutton's test coverage (check out SplitTextField.php in the patch).

It might be worth exploring the same thing we are with autocomplete in Drupal 9: weighing the pros and cons of a third party library vs a custom solution based on Splitbutton. I think most of Splitbutton can be refactored for Backdrop pretty easily, and offers the added benefit of being able to replace dropbuttons with it.