I'm not opposed, as long as the HTMLForm multi select behavior continues to work. It seems that select2 is better maintained than chosen.

What about T88250: Create tag list / tokenizer / capsule controls widget in OOjs UI?

I wouldn't say this is quite a duplicate — T88250 dealt specifically with OOUI, this is about replacing one external with another. As noted above but even more true now, select2 is somewhat more maintained and featureful (cf. https://github.com/harvesthq/chosen/pull/166)

perhaps the frontend standards group can come up with a plan for dealing with this.

I'll add that I'd also prefer Select2 as an alternative to Chosen not only because it's not deprecated, but because Select2's appearance is a closer match to OOUI than Chosen's, and Select2 has the ability to use custom themes if someone were to write an OOUI theme in the future. I'm tagging MediaWiki-ResourceLoader as Chosen is included as one of the core modules but Select2 is not.

@Ahecht Are you thinking of using this in the context of a gadget?

If so, note that libraries don't need to ship with MediaWiki core in order to use them in a gadget. You're free to (yourself, or ask an interface admin on-wiki) to import any jQuery plugins and other libraries as-needed into wiki pages alongside your gadget. These can then be listed as scripts in the gadget definition before your other scripts.

Regarding the suggestion to replace the jQuery plugin "Chosen" with Select2... I think our best practices have changed enough there that we might not want to replace this. Back when we first shipped jquery.chosen, we did not yet have a unified design style guide, and in places where we used JS, we often used jQuery UI, and basically composed different unrelated widgets together like that.

Since then, we've developed Wikimedia OOUI (and more recently, Wikimedia Codex).

@Ahecht Would you be able to use OOUI directly for this use case? Or if you're building an extension, can you use HTMLForm?

There is, for example, the OOUI ComboBox, which might serve your needs. The TagMultiselect and MenuTagMultiselect widgets come to mind as well.

• Demo
• Docs

This widget is also available to extensions when building a SpecialPage or HTMLForm via the HTMLTagMultiselectField, HTMLNamespacesMultiselectField, HTMLTagMultiselectField, HTMLTitlesMultiselectField, and HTMLUsersMultiselectField input types. This used on https://en.wikipedia.org/wiki/Special:Activeusers for example:

Change #1043158 had a related patch set uploaded (by Krinkle; author: Catrope):

[mediawiki/core@master] HTMLForm: Remove use of jquery.chosen in HTMLMultiSelectField

https://gerrit.wikimedia.org/r/1043158

Change #1043158 merged by jenkins-bot:

[mediawiki/core@master] HTMLForm: Remove use of jquery.chosen in HTMLMultiSelectField

https://gerrit.wikimedia.org/r/1043158

In the FSG meeting yesterday, @Catrope, @lwatson (Design System Team) and myself went through the various ways jquery.chosen is used today (Codesearch). Removal of the module may still be a few releases out as migration is non-trivial and we haven't started deprecation yet. But, keeping it without replacement is cheap. More important is the general direction we want to go in. We agree that we do not want to support a standalone replacement for jquery.chosen. Generally speaking MediaWiki core should not be shipping (new) standalone UI component libraries, besides OOUI/Codex.

It continues to be fine for gadgets and third-parrty extensions to use any JS libraries they want, and they can (and do) ship their own third-party libraries already. The Gadgets extension also allows these to be hosted on-wiki and embedded directly in individual gadget definitons, without needing to ship within MediaWiki core. This also offers greater flexibility in deciding if/when to upgrade. Gadgets that rely on Chosen can continue to use it (by migrating to their own copy), and can also choose to use Select2.js if they prefer that, by bundling that in their own gadget.

In terms of what we provide and recommend as a platform: We recommend that extensions use HTMLForm, which handles this automatically as part of the multiselect type (powered by OOUI under the hood today, will naturally change to Codex later). For gadgets, we recommend constructing the relevant OOUI widget directly. You can check https://doc.wikimedia.org/oojs-ui/master/demos/ and https://doc.wikimedia.org/codex/latest/components/overview.html for available widgets. If specific features from Chosen or Select2 are missing from OOUI/Codex, please do file a separate feature request showing how you intend to use it!

I'll keep this ticket open to track changes relating to removing remnant internal references to jquery.chosen in MW core and bundled extensions.

• Special:EditTags
  • uses jquery.chosen to power the multi-select dropdown menu for the "New tags" field.
  • doesn't use the standard MW-HTMLForm abstraction.
  • currently renders a plain <select> dropdown, until jQuery Chosen is called as $tagList.chosen() in edittags.js
  • change to MW-HTMLForm with HTMLMultiSelectField? That will use OOUI MenuTagMultiselectWidget under the hood, which seems to do the same thing (click to reveal options, multiple choice, typeahead).

In T53443#9890263, @Krinkle wrote:

In terms of what we provide and recommend as a platform: We recommend that extensions use HTMLForm, which handles this automatically as part of the multiselect type (powered by OOUI under the hood today, will naturally change to Codex later). For gadgets, we recommend constructing the relevant OOUI widget directly. You can check https://doc.wikimedia.org/oojs-ui/master/demos/ and https://doc.wikimedia.org/codex/latest/components/overview.html for available widgets. If specific features from Chosen or Select2 are missing from OOUI/Codex, please do file a separate feature request showing how you intend to use it!

Additionally, code using Codex will be able to use the ChipInput component for this purpose, once T345291: [EPIC] MultiselectLookup: Add new component is done.