Problem/Motivation

Improve usability and accessibility of long select lists and autocomplete tagging widgets.

Proposed resolution

Use Select2 for tags and autocomplete stuff.

Patch is almost ready, it just needs a new Select2 tokenizer that supports our "tag with, comma" syntax.

FAPI is not going to be changed, but since the latest version of Select2 only works with <select>, we need to add javascript to convert our <input type="text"> used for free tagging, to a <select>. We probably also need a submit handler in javascript that changes it back to a normal text field so our PHP code keeps working. We cannot solve this on the PHP side, since it will not work without javascript.

Remaining tasks

User interface changes

Yes.

API changes

Is this still a relevant change: The return value expected by the autocomplete API changes from array('value' => $value, 'label' => $label) to array('id' => $value, 'text' => $label).

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Task because it is a usability improvement of various UI pieces which are already in core
Issue priority Major because it greatly improves usability of long select lists (language selection in the installer, timezone selection, etc.) and Entity Reference's autocomplete widgets
Prioritized changes The main goal of this issue is usability and accessibility improvements.
Disruption Small disruption for contributed and custom modules that implement Drupal's autocomplete API because it will require a BC break.
Files: 
CommentFileSizeAuthor
#132 interdiff-2346973-126-132.txt1.76 KBchr.fritsch
#132 replace_jquery_ui-2346973-132.patch610.46 KBchr.fritsch
#126 2346973-126.patch610.51 KBphenaproxima
#123 replace_jquery_ui-2346973-123.patch20.91 KBManuel Garcia
#120 jQuery_autocomplete_ui_replace-2346973-120.patch20.91 KBjoginderpc
#117 2346973-117.patch397.23 KBvprocessor
#66 interdiff.txt414 bytesamateescu
#66 2346973-66.patch350.65 KBamateescu
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch 2346973-66.patch. Unable to apply patch. See the log in the details link for more information. View
#61 interdiff.txt1.36 KBamateescu
#61 2346973-61.patch350.71 KBamateescu
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,453 pass(es). View
#61 2346973-61-drupal-only-changes-do-not-test.patch30.81 KBamateescu
#60 core-js-autocomplete-tokenizer-2346973-60-do-not-test.patch6.56 KBnod_
#59 interdiff.txt2.45 KBamateescu
#59 2346973-59.patch346.22 KBamateescu
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,448 pass(es). View
#59 2346973-59-drupal-only-changes-do-not-test.patch26.32 KBamateescu
#58 select2-tokenizer.txt2.51 KBamateescu
#56 interdiff.txt5.18 KBamateescu
#56 2346973-56.patch346.85 KBamateescu
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,376 pass(es). View
#56 2346973-56-drupal-only-changes-do-not-test.patch26.95 KBamateescu
#55 screen.png5.59 KBaspilicious
#55 screen2.png7.19 KBaspilicious
#55 author.png5.11 KBaspilicious
#55 screen3.png6.71 KBaspilicious
#54 interdiff.txt12.46 KBamateescu
#54 2346973-54.patch343.02 KBamateescu
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,366 pass(es). View
#54 2346973-54-drupal-only-changes-do-not-test.patch23.12 KBamateescu
#43 interdiff.txt1.27 KBamateescu
#43 2346973-43.patch352.04 KBamateescu
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,233 pass(es). View
#41 interdiff.txt22.99 KBamateescu
#41 2346973-41.patch350.77 KBamateescu
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,155 pass(es), 3 fail(s), and 2 exception(s). View
#41 2346973-41-drupal-only-changes-do-not-test.patch30.87 KBamateescu
#37 interdiff.txt7.34 KBamateescu
#37 2346973-the-full-thing.patch333.79 KBamateescu
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 81,931 pass(es). View
#37 2346973-drupal-only-changes-do-not-test.patch13.89 KBamateescu
#2 Tags_edit_text_list_1_item.png53.5 KBmgifford
#2 4_results_first_accurate.png26.24 KBmgifford
#2 4_results_ONLY_3.png31.7 KBmgifford
#2 frog_chosen.png26.54 KBmgifford
#2 NO_Please_enter_1_or_more_character.png40.22 KBmgifford
#1 One_result_is_available.png181.92 KBmgifford
#1 You_are_currently_francais.png155.83 KBmgifford
#1 6_results_are_available.png142.75 KBmgifford
#1 94_results_are_available.png244.98 KBmgifford
#1 English_pop_up_button.png223.71 KBmgifford
core-js-select2.patch320.52 KBnod_
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 77,731 pass(es). View

Comments

mgifford’s picture

This looks sharp. Works as expected without a mouse which is great.

I've only looked at this with VoiceOver, but there are some issues here. I've asked for a blind user to review this and provide better feedback. As a sighted person, my use of a screen reader is pretty basic.

When I first go to the screen I'm simply informed that there is an English pop up button:
Screenshot of VoiceOver's comments on select2 dropdown

I go down and I get all 94 results:
Screenshot of VoiceOver's comments selecting dropdown

I enter in a key (not that there is any indication to me that this would have any impact - it isn't very discoverable) and I get a summary of results. It would be nice if it were able to read that shortened list of results.
Screenshot of VoiceOver's comments after hitting the letter b

When one option has been selected that isn't english and you go back to edit the dropdown:
Screenshot of VoiceOver's comments when french has previously been selected.

When you've selected one result.
Screenshot of VoiceOver's comments when one result available

mgifford’s picture

I added some elements to my taxonomy, then went http://sb8acaa3c676552c.s3.simplytest.me/node/add/article

I've attached the screenshots below, but not fleshed out the descriptions. The file names kinda illustrate the problems.

It works but also needs work.

Bojhan’s picture

Oeeh, nice. Looking forward to the A11y review

mgifford’s picture

I've uploaded so many images I can't find the patch anymore.

I am going to have to write up what it should be and then see what we can do to make it that way. We do need to have some action points.

Accessibility is probably going to be the major hurdle for this patch (and I'm not sure whether it's for Select2 or the implementation). I do hope we can git it in though as it's a nice feature.

mgifford’s picture

I'm going to write out what should happen for accessibility:

A) On Choose a language
1) Rather than saying "English pop up button" it should say "Language selection pop up. English selected."
2) On entering the pop up, the user should be told "94 results are available, use up and down arrow keys to navigate" it should say "To choose a language, enter the first few characters. 94 results are currently available."
3) When a key is pressed the user should be told that the list changed. Rather than "6 results are available, use up and down arrow keys to navigate." -- it would be nice if it was more consistent with autocomplete and would read the list.
4) If there is only one result, it should read the result. "One result is available, press enter to select it." is a pretty useless description. In my example it should read something like "Bosanski selected, press enter to save and continue."

I can't see the source code to see how viable that actually is.

mgifford’s picture

B) With the taxonomy term, it is important to provide more context as this will be very confusing.

1) When you first tab to the form you're told "Tags edit text list 1 item" but really should be told that this is an empty form and that they should start typing to either get a list of previously selected tags or to enter a new tag.
Screenshot of an initial screen when entering a tag

2) On hitting f, I'm told that "4 results are available, use up and down arrow keys to navigate" it would be nice if it were consistent with autocomplete right now and list the selection.
Screenshot of dropdown with selection

3) If there's already a tag selected, the count is off. "4 results are available" seems wrong given there are 3 in the list:
Screenshot of dropdown with 3 items selected

4) Frog is pronounced when selected:
Screenshot with frog selected from a list of f words.

5) The tags have a nice description field which is available but it isn't read to the screen reader as it's done as a title to the input form. It says "Please enter 1 or more character"
No description is available for screen reader users.

oushen’s picture

Hi. When D8 go to beta release, I will port Select2 module to D8 and we can use it for tags (and other taxonomy ref) fields, autocomplete fields and other.

nod_’s picture

Thanks oushen, any chance you can help out this patch? I'd rather have that in core in 8.1.0 if we can instead of contrib. That way we'd make sure the integration is accessible and that many more other contrib modules can use it (like rules maybe).

droplet’s picture

get the patch back.

mgifford’s picture

I had to search for a cached version of the page to get the patch:
https://www.drupal.org/files/issues/core-js-select2.patch

attiks’s picture

The summary says to use it for taxonomy, why don't we use it for multiple selects as well?

mgifford’s picture

I think @nod_ was primarily developing this as a use case to see what problems we'd run into.

There are a few accessibility problems with it at this point. I've tried to articulate how they should be improved.

oushen’s picture

attiks, at this week I will publish dev release of Select2 module for D8, with this module you can use it for all select form elements, autocomplete fields and define select2 options for custom elements by Forms API.

attiks’s picture

#13 Cool

Bojhan’s picture

Issue tags: +D8MI, +#amsterdam2014

Alright, so this greatly impacts i18n - who made a major follow up.

tkoleary’s picture

Issue tags: -D8MI, -#amsterdam2014

Thanks oushen, any chance you can help out this patch? I'd rather have that in core in 8.1.0 if we can instead of contrib. That way we'd make sure the integration is accessible and that many more other contrib modules can use it (like rules maybe).

+1 to that!

tkoleary’s picture

@mgifford @nod:

If "choose language" is not being read it's because the "aria labeledby" attribute is missing I think.

tkoleary’s picture

The summary says to use it for taxonomy, why don't we use it for multiple selects as well?

Amen to that

tkoleary’s picture

@mgifford

The "please enter one character" issue also looks like aria labeledby is missing

mgifford’s picture

Issue tags: +accessibility

We can add aria-labelledby to the 'Choose language' title in core/lib/Drupal/Core/Installer/Form/SelectLanguageForm.php

I think the "please enter one character" is a vendor issue though that's part of Select2. Not that we can't change that, but it is a change for stuff up-stream.

With any dynamic tool like Select2 WAI-ARIA is going to need to be added to add the required semantics.

Drupal.announce() is also worth looking at https://www.drupal.org/node/2014521

tkoleary’s picture

With any dynamic tool like Select2 WAI-ARIA is going to need to be added to add the required semantics.

Yes, but having said that, from my research the library already has more aria roles natively than any other and if we make that more robust it would be more responsible for us to add them upstream submitting pull requests to Select2 on github. That way others can benefit as well.

mgifford’s picture

I'm totally onboard with providing patches to Select2 and pushing them upstream. I think they'd be open and everyone would benefit.

I'm just not a JS person so won't be leading the way in developing the patch.

Xano’s picture

Can you please update the issue summary so it includes the reasons for adding this, which problems it solves, etc?

Also, this looks like Chosen. Do they really do similar things and if so, how do they differ?

mgifford’s picture

Issue summary: View changes
Issue tags: +Needs issue summary update

Took a quick look for comparisons of Select2 vs Chosen.

They do pretty similar things from what I can tell.

Bojhan’s picture

It is worthwhile to look at Kevin his evaluation at https://docs.google.com/spreadsheets/d/1vifOGL_4wgOl6sy2Os59k24saIHvwFFQ...

andypost’s picture

This would be really useful for new UI for related help topics #2351991-55: Add a config entity for a configurable, topic-based help system

andypost’s picture

andypost’s picture

droplet’s picture

Comment #6: 3,

I sent a patch to upstream and it's merged now. https://github.com/ivaynberg/select2/pull/2726

Wim Leers’s picture

This would also finally solve the many huge problems (UX-wise and otherwise) with jQuery UI Autocomplete explained at #675446-271: Use jQuery UI Autocomplete. Great work here :)

tkoleary’s picture

@Nod

Given the upstream changes to Select2 for a11y are we unblocked on rolling a patch?

mgifford’s picture

Is this going to have to get bumped to 8.1.x.?

Is there any chance that a patch will get into 8.0.x for this?

Bojhan’s picture

Version: 8.0.x-dev » 8.1.x-dev
mgifford’s picture

Status: Needs review » Postponed
YesCT’s picture

Issue summary: View changes

I put the templates in the summary, but there are details I'm not sure of.

What is the motivation here?
Why is this a feature request?
Could this qualify for beta under "prioritized change"?

YesCT’s picture

Issue summary: View changes
amateescu’s picture

Version: 8.1.x-dev » 8.0.x-dev
Category: Feature request » Task
Priority: Normal » Major
Status: Postponed » Needs review
FileSize
13.89 KB
333.79 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 81,931 pass(es). View
7.34 KB

I think it's very important to get this into 8.0.0 for multiple reasons:

Also note that Entity reference is very likely to replace the taxonomy term reference field in D8 so the last point outlined above is going to get in everyone's face soon enough.

I started with @nod_'s patch referenced in #10 but I'm not sure that creating one-off libraries for every select element that wants to use Select2 is a good long term strategy, and we should rather aim for a much better DX by integrating it right into Form API's select element via an optional #select2 property.

Haven't touched the autocomplete bits yet but this patch shows how I envision the Form API integration. I also added the #select2 option in two more places, the timezone selectors, just to demonstrate how easy it should be for everyone to use it.

jibran’s picture

+++ b/core/misc/drupal.js
@@ -86,12 +86,12 @@ if (window.jQuery) {
+        //try {
...
+        //}
+        //catch (e) {
+          //errors.push({ behavior: i, error: e });
+        //}

Comment out code.

Wim Leers’s picture

+++ b/core/lib/Drupal/Core/Render/Element/FormElement.php
@@ -128,4 +129,43 @@ public static function processAutocomplete(&$element, FormStateInterface $form_s
+  public static function processSelect2(&$element, FormStateInterface $form_state, &$complete_form) {

Why on \Drupal\Core\Render\Element\FormElement and not on \Drupal\Core\Render\Element\Select?

AFAIK there is no other element that could use it?

amateescu’s picture

Why on \Drupal\Core\Render\Element\FormElement and not on \Drupal\Core\Render\Element\Select?

AFAIK there is no other element that could use it?

Text elements that might have a different purpose than autocomplete can use it too, so why not give them the possibility? :)

amateescu’s picture

Title: Use select2 » Replace jQuery UI autocomplete with Select2
FileSize
30.87 KB
350.77 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,155 pass(es), 3 fail(s), and 2 exception(s). View
22.99 KB

Here's the complete integration with Drupal's autocomplete requirements, with proper markup escaping and all that.

The only thing left that still needs work is to provide support for our "term with, comma" syntax, which is not supported by Select2 at all. Every time this question comes up on github or other support forums, people just say to use "|" as a delimiter, but I don't think we have that luxury of choice in Drupal so we'll need to provide our own tokenizer function. I looked a bit at that code but I hope @nod_ can help out here since he's, well.. more familiar with JS :)

Status: Needs review » Needs work

The last submitted patch, 41: 2346973-41.patch, failed testing.

amateescu’s picture

Assigned: Unassigned » nod_
Status: Needs work » Needs review
FileSize
352.04 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,233 pass(es). View
1.27 KB

Fixed that last test. Let's see what @nod_ thinks about #41.

jibran’s picture

Can we have a core only patch *pretty please*?

amateescu’s picture

It's in #41?

jibran’s picture

pardon my ignorance patch looks good to me.

xjm’s picture

Let's get the beta evaluation updated to be more than boilerplate? :) It would be really valuable to summarize in that table why this is major, what the improvements for accessibility and such are, and what the disruption would be within core, for contrib, etc. :)

The diffstat for the core-only patch in #41 is nice.

xjm’s picture

+++ b/core/modules/views/src/Tests/ViewsTaxonomyAutocompleteTest.php
@@ -75,8 +75,8 @@ public function testTaxonomyAutocomplete() {
-      'value' => $label,
-      'label' => String::checkPlain($label),
+      'id' => $label,
+      'text' => String::checkPlain($label),

E.g. this change in the array structure is a (reasonably small) disruption for contrib. Etc.

amateescu’s picture

Issue summary: View changes

Improved the entire IS a bit, I hope it's more clear now :)

attiks’s picture

#48 does this mean that the keys need to be changed depending on the fact that you use select2?

Ex: if I remove the "'#select2' => TRUE" from a select, will this break the code?

amateescu’s picture

@attiks, the keys have to be changed everywhere. But that's only about the autocomplete API, not about using Select2 in regular select elements.

nod_’s picture

I don't think we need to change the keys, the naming makes more sense as it is now and it's trivial to map that on the JS side.

amateescu’s picture

I changed them because we also did it when we switched to jQuery UI autocomplete in #675446: Use jQuery UI Autocomplete, so I thought we want to follow the Select2 defaults. I don't have any strong opinion about it though :)

amateescu’s picture

FileSize
23.12 KB
343.02 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,366 pass(es). View
12.46 KB

I thought about it some more and I agree that the value => label combination makes more sense than id => text, so let's drop the slight API change and just keep the huge UX improvement :)

aspilicious’s picture

FileSize
6.71 KB
5.11 KB
7.19 KB
5.59 KB

I WANT this patch so I tested it but found some problems.

screen
- tags with spaces don't get recognised

screen3
- When editing the same node nothing gets recognised

screen2
- Why is timezone a select 2 field and country not?

author
- Can there be multiple authors? That's confusing. After the first author the autocomplete doesn't work anyway.

amateescu’s picture

FileSize
26.95 KB
346.85 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,376 pass(es). View
5.18 KB

@aspilicious, thanks for the review!

- tags with spaces don't get recognised

That's already mentioned in #41 :)

- Why is timezone a select 2 field and country not?

Yeah, the country selector is long enough to need the Select2 widget. Added.

- Can there be multiple authors? That's confusing. After the first author the autocomplete doesn't work anyway.

Fixed.

nod_’s picture

Quick review, I'm looking at the tag splitting thing.

  1. +++ b/core/core.libraries.yml
    @@ -808,3 +808,19 @@ underscore:
    +  js:
    +    assets/vendor/select2/select2.js: {}
    +    misc/select2.js: {}
    +  css:
    +    theme:
    +      assets/vendor/select2/select2.css: {}
    +  dependencies:
    +    - core/jquery
    

    Dependencies are not right, the misc file should be in drupal.autocomplete. Not here since it'd make select2 depend on core/drupal and core/drupalSettings.

  2. +++ b/core/lib/Drupal/Core/Render/Element/FormElement.php
    @@ -123,6 +124,49 @@ public static function processAutocomplete(&$element, FormStateInterface $form_s
    +      $options = isset($element['#autocomplete_options']) ? $element['#autocomplete_options'] : array();
    

    Default should be an object, otherwise the JSON will end up as [], not {}.

  3. +++ b/core/misc/autocomplete.js
    @@ -41,132 +39,51 @@
    +  var select2Options = {
    

    We might want to expose that in drupalSettings for people to be able to change it globally, not just with data attributes.

  4. +++ b/core/misc/autocomplete.js
    @@ -174,45 +91,17 @@
    +      $(context).find('input.form-autocomplete').once('autocomplete')
    

    Set a data attribute instead of a class and use it to select elements please. data-drupal-autocomplete would work.

  5. +++ b/core/modules/node/src/Entity/Node.php
    @@ -378,6 +378,7 @@ public static function baseFieldDefinitions(EntityTypeInterface $entity_type) {
    +//      ->setCardinality(1)
    

    ?

amateescu’s picture

FileSize
2.51 KB

@nod_, I was looking into the tokenizer thing as well and I got it mostly working, here's my WIP diff.

amateescu’s picture

FileSize
26.32 KB
346.22 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,448 pass(es). View
2.45 KB

Quick update for the review in #57:

  1. Dependencies are not right, the misc file should be in drupal.autocomplete. Not here since it'd make select2 depend on core/drupal and core/drupalSettings.

    Not sure that's correct, that code is just registering Select2 into our library system, and it's only dependency is on jQuery. Since we've now integrated Select2 into Form API, this is not tied to autocomplete anymore.

  2. Fixed.
  3. We might want to expose that in drupalSettings for people to be able to change it globally, not just with data attributes.

    I don't know what's the "right way" to do this. Do we usually expose stuff in drupalSettings from inside a js file?

  4. Fixed as discussed in IRC.
  5. Oops :)
nod_’s picture

This file is the problem: misc/select2.js: {} Look at all our other vendor libs, they don't have extra Drupal dependencies (this file will crash JS because Drupal isn't defined if you load only core/select2).

Here is the tokenizer thing with some improvments in splitValues. Based on #56.

amateescu’s picture

FileSize
30.81 KB
350.71 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 82,453 pass(es). View
1.36 KB

Finally understood what @nod_ meant with the separate library. Fixed that and incorporated the tokenizer from #60 into the main patch.

aspilicious’s picture

Status: Needs review » Needs work

Tag autocompletion still has issues. I made two tags:

"Some tag", "a new tag"

When editing the node you get 1 merged tag: "some tag, a new tag". The tag list in the backend looks ok, so it's a js thingie.

nod_’s picture

You can laugh at me:

diff --git a/core/misc/autocomplete.js b/core/misc/autocomplete.js
index 3817c7d..f0fae1b 100644
--- a/core/misc/autocomplete.js
+++ b/core/misc/autocomplete.js
@@ -77,7 +77,7 @@
 
     // If there are no enclosing character splitting is easy.
     if (value.indexOf(enclosing) === -1) {
-      result = value.split(enclosing);
+      result = value.split(token);
     }
     // Handle enclosed token.
     else {

Then it works.

amateescu’s picture

/me giggles at @nod_ :D

The fix from #63 fixes the problem mentioned by @aspilicious, but there's still one small issue: you can never remove a tag which contains a comma :) It is removed visually from the input element but when you save the node, it's still there, sometimes even duplicated.

quicksketch’s picture

This looks like a great direction.

Looking at the library and the patch, what approach should be used to bring consistency to non-Select2 select lists and Select2-enabled select lists? @aspilicious's image in #55 shows the differences pretty clearly. I'm guessing the default styling for Select2 would be left in place (considering there are no "skins") and the theme would take on the responsibility of styling them individually (as Seven theme styles select lists already).

amateescu’s picture

Status: Needs work » Needs review
FileSize
350.65 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch 2346973-66.patch. Unable to apply patch. See the log in the details link for more information. View
414 bytes

I'm not sure that the Seven theme styles select lists already. At least on FIrefox/Chrome on Kubuntu, the select lists look like the OS ones, and I don't see any select-specific code in firebug.

My proposal for styling is to use the Seven style guide, so even if Select2-enabled select elements won't look like the regular ones, at least they'll be consistent with the rest of the theme. We already have a dedicated issue for this: #2318665: Implement the dropdown menu component styling into the autocomplete widget, but I'm not opposed to doing that work here.

Here's a reroll for current HEAD + the small fix from #63 (Drupal only patch for review is in #61).

@nod_, do you have some time to look into that small (last) issue with the new tokenizer found in #64?

LewisNyman’s picture

I'm not sure that the Seven theme styles select lists already.

It does, but only on Webkit because cross browser support for styling the native
element is poor. #2207391: Style select elements in Webkit only

LewisNyman’s picture

I have to say this is looking very good. I recommend we stick with the default library styling, and work on the Seven styling in #2318665: Implement the dropdown menu component styling into the autocomplete widget

nod_’s picture

Assigned: nod_ » Unassigned

Umm looks like a new version of select2 got out (in beta still), the catch is that select 2 can't work with inputs anymore, it expect a select element (it makes sense given the lib name). See Select2 v4 beta. The consequence for us is that the current tag input field for taxonomy won't work with the new version of select2. That's a bummer.

We can transform tag input in a select with JS (progressive enhencement and all) but the data sent to the server will be different, unless we serialize the values from select2 in the input on submit.

amateescu’s picture

Yes, I saw the new version of the library and that it contains quite a few things that break our current integration, but that doesn't mean we should drop this issue, I hope?

the data sent to the server will be different, unless we serialize the values from select2 in the input on submit.

This doesn't look like an unsolvable problem :)

LewisNyman’s picture

hmm, I don't understand. How would you add a new value that doesn't exist as an option in the select dropdown? Or is that now outside of the use case of Select2?

amateescu’s picture

@LewisNyman, a select dropdown is needed just as the initial element, adding new values / tagging works just like before: https://select2.github.io/examples.html#tags

Wim Leers’s picture

Indeed, looks like we can work with Select2 version 4 just fine; we'll just have to change #type => input to #type => select.

LewisNyman’s picture

I think a select element feels like a much better JS fallback than a blank text input.

Wim Leers’s picture

#74: except that you can type in a blank input[type=text], but the <select> Select2 uses would be empty in our case, since free tagging in Drupal allows for thousands of terms to be created, not all of which can be listed. Disable JS and look at https://select2.github.io/examples.html#data-ajax for a more accurate fallback UX.
And that is actually a great point: the no-JS experience. Do we even still care about that? E.g. dropbuttons are also completely broken without JS.

quicksketch’s picture

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: https://github.com/select2/select2/issues/17.

aspilicious’s picture

We have a site with more than 6000 tags and counting (since september 2014). We can't use select fields for those in combination with select2 because it's nearly impossible to render.
Making tags a select field would introduce severe performance issues.

As I do see the advantage for 95% of the use cases I would like to have a fallback to the current behaviour. But that would be hard because one widget is a textfield and the other a select widget :s

Damn...

Can't we fund a JS genius to make a drupalSelect fork of select2? XD

droplet’s picture

@#77,

You won't tagging 6k tags in ONE node ??

Technically, we can rendering select list in client side (converting from input).

see patch in #66, it still making a lot of changes to JS/PHP code. It's a sign that D8 still having bad Autocomplete API architecture in CORE. I think we need to shape it better API to adopt different JS libs for future developers (without CORE JS & PHP patching).

attiks’s picture

#78 We have similar (and bigger) vocabularies as @aspilicious mentioned in #77, outputting a select list is not going to be an option. Most of the entities are tagged with multiple terms.

Dream scenario:

Have a widget that renders the right HTML depending on the amount of data and attaches the right libraries.

For example (boundaries to be defined in config):
10 or less options and without tagging: output select, no select2
200 or less options and without tagging: output select, use select 2
200 or less options and with tagging: output text, use select 2
201 or more options and without tagging: output empty select, use select 2 + ajax
201 or more options and with tagging: output input, use select 2 + ajax

Really nice to have: Add support for hierarchical vocabularies as well, so site user can select parent term as well and they are rendered as nested.

amateescu’s picture

Whoa, hold on there.. isn't #72 clear enough in this regard? :)

#73 is wrong, there's no change needed on the PHP side (at least for the element declaration), we just need to convert the text input into a select before Select2 is initialized on that element.

attiks’s picture

#80 I'm probably missing something, but what is the policy for non js browsers, 'cos if we output a select for free tagging it will not work without javascript. Unless we are converting the input to a select using javascript?

amateescu’s picture

Unless we are converting the input to a select using javascript?

Bingo! :) Just as @nod_ said in #69 when the discussion about the new version of Select2 started.

attiks’s picture

Issue summary: View changes
attiks’s picture

#82 I've updated the IS, but by reading the comments the API change is no longer needed?

aspilicious’s picture

I'm a JS noob, so I can't say anything useful, but I think when it's done we need to manual test this with 1000+ tags to see if it has any effect. Just to be sure. I'm always ready for doing that when needed.

It will gain me lots of credits with the UX designers at work ;)

quicksketch’s picture

Sorry, yeah I kicked off the discussion in the wrong direction there. 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.

Wim Leers’s picture

#76/#77: did you look at how https://select2.github.io/examples.html#data-ajax (that specific linked example) works? It works with an empty <select>, for which <option>s are generated by Select2.

#86: that sounds very doable? But I agree that it's very unfortunate that the input[type=text]-based autocomplete use case is no longer directly supported by Select2. I really wonder why the author did that? After all, what Select2 presents UI-wise resembles a input[type=text] much more cosely than a <select>, so even in that regards it's a puzzling change. The removal of a input[type=hidden] dependency makes sense to me, the removal of input[type=text] not so much.
Does anybody of us know the Select2 author? Or has any of us followed its development closely? If so, then perhaps we can start a conversation with the author? One of us should reach out to the author IMO; Drupal 8 would be one of the most prominent users of Select2, I imagine, so perhaps he'd be willing to add this back for us. Or perhaps he'll manage to convince us of his reasoning :)

nod_’s picture

Reason was code simplification. it's easier to deal with options elements than splitting a string, also the return is cleaner for the backend, getting an array of split values is better than a string of values to split. It's in the github queue somewhere.

Not sure how messy it'd be to add back input support, but I guess we should reach out in any case.

kevin-brown’s picture

I'm the maintainer of Select2, and I'm interested in working together to fix the current lack-of-text-input issue.

I removed support for hidden inputs (<input type="hidden">) because there was no non-js fallback. Non-js users would be presented with absolutely nothing, and most likely any validation would be failing (pretty silently) because of that. All in all, it wouldn't be a great user experience, and it was something I wanted to avoid. Now, I didn't realize that people were using a text input as the fallback until about a week ago, and because of that much of the code is expecting a <select>, which is great because we don't have to special case that much.

The problem with the old implementation largely revolved around initSelection, a badly named function that handled the job of converting the value attribute to a set of data objects. I'm interested in working together to figure out what would need to be done to have Select2 function as an autocomplete for Drupal, but my knowledge of how the Drupal internals work is very limited.

We are tracking this issue at https://github.com/select2/select2/issues/3022 as well.

Wim Leers’s picture

That's awesome news! Thank you!

Basically, all there is to know is this:

  1. Drupal has supported "free tagging" (also known as folksonomies) for … 10 years or so. You can type any tag you want, and type a comma to indicate a next one.
  2. To help users find/select existing tags, there is an autocomplete, which takes the space-trimmed string after the last comma — if any — and asks the server for autocomplete matches. (It's never been quite as awesome as Select 2 though :)) i.e. foo, bar, baz -> "baz" is being autocompleted.
  3. To type tags containing commas, we wrap them in double quotes. i.e. Some Person, "Leers, Wim", Another Person has 3 tags: "Some Person", "Leers, Wim" and "Another Person".
    (This behavior would probably need to be implemented on the Drupal side, which is exactly what @amateescu did in #66, until @nod_ remarked in #69 that Select2 version 4 was about to be released, and this issue kind of got stuck on what to do now that Select2 no longer natively supports input[type=text]. In other words: you probably wouldn't even have to care, as long as we can still make it work just like we did for Select2 version 3.)
  4. Most importantly to you: what is described above, including the examples, are exactly what is sent to the server (commas, quotes, spaces and all). Basically, our UI has always been input[type=text] with some UI additions for autocompletion that helped the user get data in there in input[type=]text] faster and more easily — hence degrading "gracefully" to a very unhelpful, autocompleteless, mindblowingly simple UI: the plain input[type=text].
nod_’s picture

Thanks for the offer kevin-brown. Hopefully we can work this out :)

Bojhan’s picture

Issue tags: -Needs usability review
Dom.’s picture

Also maintainer of Search Autocomplete interested in helping if needed : #2442699: UX improvment on autocompletion

Dom.’s picture

njbarrett queued 66: 2346973-66.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 66: 2346973-66.patch, failed testing.

njbarrett’s picture

Now there's a release candidate for Select2 4.0, do you think now is a good time to create a new patch for this issue?

Wim Leers’s picture

Indeed, more than a month ago, the solution on the Select2 side was merged: https://github.com/select2/select2/issues/3022#event-243644862, https://github.com/select2/select2/pull/3051.

quicksketch’s picture

Component: base system » javascript

Select2 4.0.0 was released about 2 week ago. Looks like this issue back on. ;)

joelpittet’s picture

Issue tags: +frontend

Tagging frontend for sprint.

mgifford’s picture

Should we bump this to 8.1?

tkoleary’s picture

@mgifford

Given other priorities, perhaps. Although given the fact that it is unquestionably an a11y improvement, maybe not.

mgifford’s picture

@tkoleary I don't see the accessibility improvement. At least not when looking at the examples here:
https://select2.github.io/examples.html

It is a simple tool, but there are a lot of basic problems listed here:
http://wave.webaim.org/report#/https://select2.github.io/examples.html

I don't know how many are just part of the example code though.

I haven't had time to really look at it though. I do know that jQuery UI's autocomplete has had quite a lot of accessibility testing.

Can you point me to a comparison of the two for accessibility? Or even the documentation on the a11y work that's gone into Select2?

tkoleary’s picture

Last info I looked at was this issue https://github.com/select2/select2/issues/2499 that both you and I commented on which is now closed fixed. Since that time new a11y issues have been opened in 4.0, but (based on my own unscientific testing) 2499 puts Select2 well ahead of jquery autocomplete.

Here are the open a11y issues in select2 4.0

https://github.com/select2/select2/pull/2875 this one was opened after 2499 and was merged in on 12/09/2014
https://github.com/select2/select2/issues/3238 closed fixed
https://github.com/select2/select2/issues/3144 this one is still open as an enhancement but no longer marked a bug

I could not find other issues. We have an individual working with us here in Boston who may be able to test 4.0.

mgifford’s picture

I definitely think there has been progress with Select2 on accessibility, but I haven't had time to test it and it isn't clear to me that others have either. One of the last comments in #2499 is "Unfortunately I have no idea how to thoroughly test it as I only have limited knowledge of how Orca works, but perhaps someone else can help with testing."

That doesn't give me a lot of confidence.

I don't know how testing has been done or by whom. Select2 seems to have quite a few powerful options. I don't know if any of those have been tested.

There's some good addition of ARIA, but I still don't see how it's significantly better than jQuery UI for accessibility.

tkoleary’s picture

Some initial testing by Tyler Littlefield here in OCTO shows that in fact there is still a good bit of work to do. I plan on creating some new issues in the Select 2 queue on github.

mgifford’s picture

The WP folks did a nice review of Select2 because they were considering it for WP Core - https://make.wordpress.org/accessibility/2015/09/07/accessibility-userte...

It would be great if we could work with them a bit more on addressing these issues.

subhojit777’s picture

Issue tags: +Needs reroll
mgifford’s picture

Gaelan’s picture

Assigned: Unassigned » Gaelan

Rerolling.

catch’s picture

Version: 8.0.x-dev » 8.1.x-dev

subhojit777 queued 66: 2346973-66.patch for re-testing.

Wim Leers’s picture

Apparently there's a competitor to select2 that pays homage to select2, but tries to be better/simpler: https://github.com/arendjr/selectivity

mstrelan’s picture

Selectize.js also claims to be have a few advantages to Chosen, Select2 and Tags Input. and http://selectize.github.io/selectize.js/ and could be worth considering.

tkoleary’s picture

@wim leers

Apparently there's a competitor to select2 that pays homage to select2, but tries to be better/simpler: https://github.com/arendjr/selectivity

It does look simpler. Also bad on A11y but Select2 has not made much progress either, same for selectize. Just tested all three with screen reader.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

vprocessor’s picture

Status: Needs work » Needs review
FileSize
397.23 KB

attempt to reroll

Status: Needs review » Needs work

The last submitted patch, 117: 2346973-117.patch, failed testing.

tkoleary’s picture

@vprocessor

Looks awesome! Despite failing tests it seems to work fine when I spin it up on simplytest.me.

One thing I noticed, the descriptive text would need to change (or just go away) in several places eg.

Enter a comma-separated list. For example: Amsterdam, Mexico City, "Cleveland, Ohio"

But that's a good problem to have.

joginderpc’s picture

Status: Needs work » Needs review
FileSize
20.91 KB

Updated all files with newer version of D8. Let's see if test passes.

Status: Needs review » Needs work

The last submitted patch, 120: jQuery_autocomplete_ui_replace-2346973-120.patch, failed testing.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Manuel Garcia’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
20.91 KB

Rerolled, was just a simple conflict on core/misc/autocomplete.js

Status: Needs review » Needs work

The last submitted patch, 123: replace_jquery_ui-2346973-123.patch, failed testing.

Bojhan’s picture

Assigned: Gaelan » Unassigned
phenaproxima’s picture

Status: Needs work » Needs review
FileSize
610.51 KB

It looks like the re-roll was botched at some point, and a missing file (or several!) was causing the test failures. Here's a new re-roll against 8.3.x, using Select2 4.0.3.

I apologize for the colossal patch size; the overwhelming majority of it is the Select2 library.

EDIT: Now that core has functional JavaScript testing, it seems like we might want a functional test of this widget against, say, a taxonomy term reference field. Do folks agree?

Status: Needs review » Needs work

The last submitted patch, 126: 2346973-126.patch, failed testing.

amateescu’s picture

Note that #2788209: Entity reference field "Autocomplete matching: Starts with" option does not work added a (small) javascript test for the autocomplete widget, so we could expand it here if needed.

But IIRC, this issue was blocked on the fact that Select2 is not as accessible as we need for core, see comments from #103 to #107.

phenaproxima’s picture

Looks like the WordPress people were interested in perhaps devoting some brainpower to fixing these issues; I can't tell if anything came of that, but maybe we could do the same? I really like this library and would quite like to see it in core.

tkoleary’s picture

+++ b/core/assets/vendor/select2/css/select2.css
@@ -0,0 +1,484 @@
+    .select2-container .select2-selection--single .select2-selection__rendered {

Guessing this was copied from select 2 css and altered and that's where the indented rules come from. We should follow drupal CSS coding style here with no indents.

At first glance I thought it was Sass. :)

droplet’s picture

All good work here.

I think we need some final calls:
A1. [Frontend] Final analysis of the Performance. Select2 isn't a small kid thought.

If we can't pass A1. It's time focus on contributed and pick another one instead of dead loop :)

A2. [Accessibility] Final analysis of select2 itself (without Drupal)

A3. Basic usage. Testing in cross browsers (Checking the supports table in Select2 is not enough. In Drupal, we have very diff requirements.)

B. [JavaScript] Possible way to improve the Accessibility problem in Select2 Upstream & Drupal ourselves.

With my last patch to Select2 upstream ( https://www.drupal.org/node/2346973#comment-9255223 ), I think there's limitation to patch everything in Select2 upstream. Select2 also has itself design principal.

chr.fritsch’s picture

Status: Needs work » Needs review
FileSize
610.46 KB
1.76 KB

I could resolve some dependency issues. Looks like there is no Select2 object in version 4.

Status: Needs review » Needs work

The last submitted patch, 132: replace_jquery_ui-2346973-132.patch, failed testing.

RajabNatshah’s picture

+1 This will be very very nice if we do have it in Drupal core and out of the box.

Bojhan’s picture

Assigned: Unassigned » nod_

I think this needs escalation to product, with a clear answer on 1.

Assigning to nod_ to provide some guidance.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

pdenooijer’s picture

I am looking forward to start using this feature, is there any update on the status of this issue?

Manuel Garcia’s picture

Issue tags: +Needs reroll

Most conflicts are easy enough to fix, however core/misc/autocomplete.js has been changed by #2823589: Improve IME handling on Autocomplete so I'm stepping away from this reroll in fear of messing things up :)

droplet’s picture

jonathanshaw’s picture

I suspect a lot of conflicts are not showing up because the patch hasn't been updated to allow for the fact that a lot of Entity Reference code has moved out of that module.

More generally:
Everyone wants this. But it's not showing any signs of going anywhere.
There's 4 tough hurdles to climb:

  1. Get Select2 working as a Drupal element and entity reference widget
  2. Get it meeting Drupal accessibility etc. standards
  3. Switch it in place of jquery autocomplete in the default entity reference widgets
  4. Deal with the consequences of adopting it in Drupal's admin UIs

What chance of us achieving all this in one 15k-lines patch in 8.x?
How about we split this into 3 steps:

  1. Get select2 working in contrib, getting it feature-complete as an optional element and widget
  2. Move it into core as an experimental module, working on accessibility etc.
  3. Create an issue to deprecate the current jquery autocomplete entity reference widgets in favour of the select 2 ones
  4. Create an issue to enable it globally in the admin UI replacing jquery autocomplete and deal with whatever unforeseen consequences that has
axel.rutz’s picture

#140:
> How about we split this into 3 steps: ... (4 steps)

YES sounds very reasonable.