🇭🇰Hong Kong @droplet

I believe there is something more than just updating the version number.

The patch is outdated. No matter code format or code logic.

and a bug:
🐛 "core/drupal.checkbox" (misc/checkbox.js) has never loaded on user permission page Fixed

What blocking server-side doing the Permission update when "AUTHENTICATED USER" is checked? It reduced a lot of extra dummy checkboxes and need not call toggle on page loading.

Don't it a UX problem?
If "AUTHENTICATED" is checked (on page load, load from DB), we see all checkboxes are checked.
Now, unchecked "AUTHENTICATED", only some is still checked. I expected all still checked.

I have very low interest in it because I can deal with this problem smartly personally.

For those who are interested, I think you need to figure out the root problem first. Browser? CPU? jQuery? Drupal Code? or Plain JS?

Obviously, this has a basic rendering problem, so you need to wait.

// copy it into drupal.js. Don't use Console to do it. And check your RAM usage when you open Console. To restart browser after a few tests to reduce the side-effect.

// change the below "100" to "1" and open the Console tab first. Otherwise, your browser may hang or run into RAM problems.

  $(document).ready(() => {
    var output = '';

    for (i = 0; i < 100; i++) {
      output += jQuery('tbody').html();
    }

    jQuery('.permissions tbody').append(output);
  });

  window.addEventListener('load', (event) => {
    console.log(document.querySelectorAll('[type=checkbox]').length);

    console.time('q');
    console.log(document.querySelectorAll('[type=checkbox]:checked')[40]);
    console.timeEnd('q');

    console.time('q2');
    const allCheckboxes = [];
    document.querySelectorAll('[type=checkbox]').forEach(function (v) {
      allCheckboxes.push(v.value);
    });
    console.log(allCheckboxes);
    console.timeEnd('q2');
  });

For 40,000 elements,
to query one element taken 15ms
to get all values taken 48ms

IMO, this is very acceptable.

** Oh. You can't test above snippet in Firefox. There's a browser bug in Firefox under above heavy load or something I missed. But Firefox rendered much faster than Chrome when you output HTML rather than use JS above

I think Drupal's initiatives are not transparent enough. It should not ask or invitation only to join in private to get extra information or make their contribution. Talented developers are busy and shy.

You can get the thing done and very controllable. But your products are standard quality only, or lower than standard. When an alpha/beta enough module released on Core Issues, it's too late to make a change.

Avoiding the echo chamber.

If we think out of the box, we can change the tagging and multiple selection design. So call it Drupal Pattern.

For instance, we can use the WordPress way to add a tag. Then, we only need a lightweight SINGLE-selection lib (dropdown + filter)

I appreciate the hard-working on the WCAG reviews but there are many basic problems we have to address them.
(It helps us to save our time for difficult WCAG reviews.)

#214

Generally, unstyled tagging lib can kick it out.

For unstyled tagging, we need to provide a way to edit the middle tag. For example, we expected to change "JavaScript" below will popup another new list to select. (This is a Code bug, UX problem, also WCAG I think)

"CSS, JavaScript, HTML"

https://www.drupal.org/project/drupal/issues/1329742 🐛 Autocomplete with tagging silently discards invalid input Needs work

data consistency would be a priority problem it should be reviewed. Also, a lib returned ARRAY better than CSV-alike STRING.

ARRAY > ALWAYS COMMAS ONLY > CSV-alike (Drupal)

@jfs.csantos,

AFAIK, after some point of 2016 Mid ~ 2017, you able to create "Yet another Select 2" in d.org freely.

With current movement, I think it's a bit hard to get Select2 into CORE.

and there's a selectWoo issue:
https://github.com/woocommerce/woocommerce/issues/16003

@mgifford,

Good news! that is a @automattic supported project. and other supports from waggl.com

@drewB I'd do it with PRs if I thought they would get merged in, but I doubt they will.

I have same concern as @claudiulodro in #131. I believe we need a smiliar fork or custom extension as woocommerce/selectwoo in druapl also.

1. and recently, when I worked on a custom project, I found the responsive doesn't work very well in select2 in many cases. e.g. rendered as a close Modal markup, Tabs. When it's shown, `width` didn't set correctly. ( https://github.com/select2/select2/issues/3278 )

2. down arrow on focus doesn't work. ( https://github.com/select2/select2/issues/4514 )

Another choice:
https://semantic-ui.com/modules/dropdown.html

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.

@#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).

Comment #6: 3,

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

get the patch back.