Some initial thoughts:

• I don't think that tags should be editable. I don't think it makes much sense conceptually: if you added the category "sports" to an article by mistake instead of "food", it makes more sense to remove the former adding the later, instead of modifying the "sports" category to become "food". This helps to keep tags simple: one main action/selection and the remove action.
• When the control is shown with both an input and a tag area, some adjustments can help to make the component look more connected. Adjusting the border radius on the touching corners and avoid the double borders (e.g., removing the bottom border of the tag area), and making the tag area slightly darker using Base90 (#F8F9FA)

Current	Proposed

In T162965#3182437, @Pginer-WMF wrote:

Some initial thoughts:

• I don't think that tags should be editable. I don't think it makes much sense conceptually: if you added the category "sports" to an article by mistake instead of "food", it makes more sense to remove the former adding the later, instead of modifying the "sports" category to become "food". This helps to keep tags simple: one main action/selection and the remove action.

I agree, I think editing tags is a weird UX. Adding to this, I think it also adds an unnecessary complication in terms of behavior.

• If you have a menu, or predefined values, what happens when you click a tag? Is clicking a tag "selecting" the tag, or "editing" the tag? It's unclear.
• The entire widget behaves as a sort of "select widget" (definitely a group widget) so clicking a tag makes sense if it is a selection (single or multi) but I think that mixing it to be sometimes a select and sometimes an edit can be super confusing.
• And if we allow for editing - do we allow for editing even when there's also a selection behavior? How do we differentiate the two? Is, in that case, a click 'edit' or 'select'? Is a double-click edit? do we add an action "dotdotdot" menu to items with "edit/select" actions? etc.
• Even if we allow editing, it gets tricky. Say I edit a tag from "foo" to "bar" - now, the widget rechecks whether "bar" is a legal value. If my widget is not "allowArbitrary" and has a set of allowed values, "bar" might not be a legal term, and so it won't be added. At this point, can I cancel the operation? If we take the editing experience into the input (inline or outline) then canceling, while possible, is really weird, and is basically the same as just adding the widget again. It's just confusing.

Honestly, I think tags are meant to be relatively small displays of data - small enough that having the user delete and re-add is a better experience than edit a tag. We could do something like "on selecting the tag, its text goes into the input" which would make the behavior something like "I click 'foo'" -> "My input shows 'foo'" -> "I edit the word 'foo' in the input to say 'food' and press Enter to re-add it" -> "I can now remove the tag 'foo', or not."

If we decide editing is essential, my personal preference is to make it a feature of the TagItemWidget itself (so you can edit "in place") but that would require an action menu to differentiate "select" action from "edit" action.

• When the control is shown with both an input and a tag area, some adjustments can help to make the component look more connected. Adjusting the border radius on the touching corners and avoid the double borders (e.g., removing the bottom border of the tag area), and making the tag area slightly darker using Base90 (#F8F9FA)

Beyond the styling suggestions, I'd add that we might want to consider allowing other types of inputs. I've added the technical ability to set the input into any OO.ui.InputWidget so we could, for example, use an InputWidget that is also a LookupElement, etc. However, that creates a couple of interesting issues in itself.

For example, if the input is "inline", then the code (and behavior in general) expects a "simple" input (the code takes the raw this.$input and embeds only that part into the inline element list, to make the input somewhat invisible). I didn't force this choice in the code (you can, technically, choose both 'inputPosition:inline' and 'inputWidget: new OO.ui.SearchInputWidget() for example) but that would, at the moment, look terrible, and break. And since the inline input is constantly being resized (again, to allow for a sort of "hidden" input behavior, so we type as if the entire widget is writeable) then having that widget in that input makes no sense to begin with.

(By the way, the issue that NumberInputWidget is not an actual InputWidget means, in this case, that it cannot be used in the widget as-is, which is pretty bad. We should try to fix NumberInputWidget to be an actual InputWidget)

In any case, I think it's worth considering the actual different behavior we want between inline and outline inputs. Do we want drop-down-menu behavior to be only a feature of the outline input, or do we want to allow that to the inline input as well, like a type-ahead-suggestion feature? That would be more challenging technically, but maybe more consistent UX-wise.

Anyways, I think we should also consider these aspects. They came from CapsuleMultiselectWidget, but that doesn't necessarily mean we should keep them as they are in this new widget.

Please also consider carefully how keyboard only, or screenreader users have to interact with these things. They possibly need to know any of the following:

• The grouping/list that are the tags
• Content or name of each tag.
• Type of tag, in case of multiple colours, or logos etc
• State of the tag: disabled, readonly etc..
• How to remove one
• How to add one
• How to order them
• How to navigate the autocomplete.
• How to navigate tag specific menu

See also T147811: Unify mw.widgets.CategorySelector and ve.ui.MWCategoryWidget.

From the description:

Captured screens in the wild of (CapsuleMultiselectWidget) shortcomings:

That looks like a screenshot of ve.ui.WMCategoryWidget, not mw.widgets.CategorySelector.

@Prtksxna You're correct, just resembles how confusing the situation of similar and only different in little bits tag component widgets has become. Updated task description.

Merging this with parent task and file sub-tasks on specific issues.