Implement chips based autocomplete designs

Seeing it's major I'll work on the specs and I'll post here the final designs & link to it asap. Work in progress happening here with initial states designed so the initial work can be based on them: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...

I've almost finished the designs with variants for other usages of chips like filters (not that we need now, but it might be useful for future JS UI elements).
There are 2 remaining questions I'd love to hear other people thoughts on:

1. The focus interaction when there's the close icon: I think the focus should mark only the close icon instead of the whole element because it's what it is going to be "actionable. But when the interaction is via keyboard (removing chips via the keyboard), I'm not sure if focusing only the close icon makes sense. Does anybody has any suggestion?

2. Long title referenced entities: to crop or not to crop?

Apart form this, I think the implementation could move on.

I think it makes sense to focus on the "remove" function as this is the action to take when focusing the element.

From a design POV I like the idea to crop a long text, but I think we'd then need to have the full title to appear when you hover the item.
For screen readers it shouldn't be a problem if we truncate the text with CSS3's text-overflow: ellipsis;

I've made some adjustments to the Design in Figma.

As for the focus on the remove action on the active chip item not having an sufficient contrast we could lighten up the "green ring" by 20% to make it pass. This way we should get a ratio of 3.52:1.
Left: Claro focus green, Right Adjusted Claro focus green (20% brighter)

Also the link to the updated component: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...

Specification updated: https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...

Closed #3023298: Tag / entity reference fields style update as a duplicate for this, and removing the Accessibility review tag for now since no approach has been decided yet.

Design suggestion
I'd like to recommend an approach where the chips are not inside the text input. It's not semantically correct to have interactive elements inside an input, and that happens to be where many of my evaluations of autocomplete libraries failed. At some point, Wordpress was doing this, although the current docs suggest that they converted to a chips-in-input approach. I don't have a local Wordpress ATM, but this is an example of what I recall:

Implementation suggestion
It's not clear if when/if Drupal will stop using jQuery UI autocomplete. A pretty nice library was created to replace it #3076171: Provide a new library to replace jQuery UI autocomplete, but there are several obstacles to getting that completed + there's less urgency to make the switch as jQuery UI is again actively maintained.

Despite this uncertainty, it may be possible to implement this in a fairly library-agnostic manner. I could still rely on Autocomplete events, as any library Drupal switches to will likely have equivalent events. If the contents of the event handler avoid the jQuery UI API and stick to standard JS/DOM interaction, then the chips feature could probably tolerate switching to a new Autocomplete library without much fuss. This would require some research to confirm it's possible, but as someone who spent considerable time with jQuery UI Autocomplete's API, this seems feasible.

There's some JS in the a11y_autocomplete module that may be useful here, it uses chips for multi select and the new Drupal autocomplete library

Thanks for working on this.

For anyone looking for a production ready solution, the Tagify module works really well, and is experiencing explosive growth, with +800 new installation the last two months.

I've created an issue https://www.drupal.org/project/tagify/issues/3380516#comment-15310408 and I'm currently working on integrating the designed functionality into the Tagify module. Please feel free to share your thoughts and feedback on this proposed feature.

There's nice UI issue closed, sounds related #3302624: Allow to control autocomplete labels and values separaterely

The Claro theme was approved for removal in #3576460: [policy, no patch] Deprecate and remove Claro.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3576668: [meta] Tasks to deprecate Claro and the removal work in #3584638: [meta] Tasks to remove the Claro theme.

Claro has moved to contrib