The FilterChip Figma spec sheet has been completed so the task is ready to be implemented.

Change 921586 had a related patch set uploaded (by Jkieserman; author: Jkieserman):

[design/codex@main] add filter chip and filter chip input to codex

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

Change 921586 had a related patch set uploaded (by Anne Tomasevich; author: Jkieserman):

[design/codex@main] FilterChip, FilterChipInput: Add components to Codex

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

Hey @bmartinezcalvo, I have a question about the interactivity of the FilterChip. The design spec shows that the entire chip should be clickable and focusable, but I'm not sure why - what happens when the chip is clicked? Showing the pointer cursor and adding hover/active styles makes it seem like you should be able to change the state of the chip or drag/move it.

Are these things that we should implement? I was looking at the OOUI TagMultiselectWidget and see that you can do the following:

• Drag chips to reorder them
• Click on a chip to edit its text

Do we want the same behavior for FilterChip and FilterChipInput?

Also, should these things be implemented within FilterChip, or only FilterChipInput?

For draggable chips, I'm not sure. Should a standalone chip be draggable? Where would you even drag it to?

For clicking on the chip to edit, that can only happen in the FilterChipInput, so I think it should be part of that component and not FilterChip itself.

@AnneT the only use cases I found for FilterChip interactivity are the removable and the clickable. You can find the clickable one in Recent changes or Search results where you can select the FilterChip and then a panel is displayed. What means that we should also implement the selected state, so I will update the Figma spec if we agree on it.

Regarding the Drag, do you know any existing real use case with that behavior? If not, we can leave it off the MVP.

I think all states should be implemented within the FilterChip as specified in the spec. Then, in the FIlterChipInput we will implement the states of that input (e.g. error state).

@bmartinezcalvo thanks for the details! It does sound like we should add the selectable state.

I don't know of any use cases for dragging...it seems like the order of the chips in the FilterChipInput should not matter. I wonder if @Catrope (or @Volker_E when he's back) know of any use cases for draggable filter chips?

@AnneT I've been working in the design proposal for selected FilterChip and checking the rest of Codex components I've detected that we don't have any other selected components with the states used in the current selected FilterChip in production. So I've created 2 proposals:

Option 1:

Using the current states used in production (blue border and light blue bg). Check Figma prototype.
Pros:

• More subtle

Contras:

• We don’t have any other selected system element with those styles
• It’s too subtle when placed within too many chips or elements
• FilterChip uses the same styles as Neutral normal button (or ToggleButton), excepted in this selected state that it’s different
• Tokens used in this selected state were not created for selected items

Option 2:

Using the styles used in ToggleButton. Check Figma prototype.
Pros:

• Same styles as ToggleButton
• Tokens used were created for selected/active states

Contras:

• We don’t have a quiet inverted button to use in the remove button

Keep in mind that we will need to add the following states related with selected:

• selected
• hover-selected
• active-selected
• focus-selected

Here you can check all the states for each proposal commented above.

cc: @RHo let us know your thoughts on this.

@bmartinezcalvo another pattern i noticed on other design systems is that when they need to have selectable chips they opt for:

• not displaying the remove button,
• and instead displaying a leading icon (e.g. checkmark).

i'm wondering if having a chip that is both removable and selectable is a "paradox". what do you think? for example, if you we select one or more item from a list, why would it be possible to also remove said items from the list?

In T324223#8998222, @AAlhazwani-WMF wrote:

@bmartinezcalvo another pattern i noticed on other design systems is that when they need to have selectable chips they opt for:

• not displaying the remove button,
• and instead displaying a leading icon (e.g. checkmark).

i'm wondering if having a chip that is both removable and selectable is a "paradox". what do you think? for example, if you we select one or more item from a list, why would it be possible to also remove said items from the list?

@AAlhazwani-WMF thank you for flagging this. I think both chips are possible: one being removable (and selectable) and the other being just selectable. You can check the first one in Recent Changes, where you can select one of the chips and also remove them from filters.

I think we will need to implement these 3 different type of chips:

• InfoChip: just informative
• FilterChip (this one): removable and also selectable
• ToggleChip (or SelectionChip) (new one): just selectable (not removable)

But, one pattern we could implement is the check icon as starIcon always a chip is selected. But not sure if it works with the remove button in the same chip:

In T324223#9000641, @bmartinezcalvo wrote:

In T324223#8998222, @AAlhazwani-WMF wrote:

@bmartinezcalvo another pattern i noticed on other design systems is that when they need to have selectable chips they opt for:

• not displaying the remove button,
• and instead displaying a leading icon (e.g. checkmark).

i'm wondering if having a chip that is both removable and selectable is a "paradox". what do you think? for example, if you we select one or more item from a list, why would it be possible to also remove said items from the list?

@AAlhazwani-WMF thank you for flagging this. I think both chips are possible: one being removable (and selectable) and the other being just selectable. You can check the first one in Recent Changes, where you can select one of the chips and also remove them from filters.

I think we will need to implement these 3 different type of chips:

• InfoChip: just informative
• FilterChip (this one): removable and also selectable
• ToggleChip (or SelectionChip) (new one): just selectable (not removable)

But, one pattern we could implement is the check icon as starIcon always a chip is selected. But not sure if it works with the remove button in the same chip:

Let's keep this task to be scoped to the filter chip and move exploration of the selectable filter chip to the relevant task. But FWIW I agree with the version where there is no "x" remove icon on selectable chips, but rather the addition of the checkmark when selected. This component is already created in Growth features and the Commons Computer Aided Tagging (CAT) feature. This closed task T280681 has more background in the thread but it was something that @ATomasevich worked on as well.

Clarification to my comment above in that I think of the example with RecentChanges as not a "selected" chip but a chip that is in an editable or 'open' state to allow changes to the filter condition.
It does seem like an edge case and I would propose distinguishing this from the selectable chips spec.

A specific recommendation to clearly indicate this case where the filter is being edited or “open” state is to separate to the “x” close action from the action to open it for editing. Quick sketch of what I mean:

Secondly, ideally the menu that is opened should be visually attached/closer to the chip being edited.

In T324223#9000954, @RHo wrote:

A specific recommendation to clearly indicate this case where the filter is being edited or “open” state is to separate to the “x” close action from the action to open it for editing. Quick sketch of what I mean:

Secondly, ideally the menu that is opened should be visually attached/closer to the chip being edited.

@RHo I've created a new version for the editable/open chip, separating the chip from the remove button as you comment. The remove button could be within a white circle so we can visually separate the chip from the remove:

Change 921586 merged by jenkins-bot:

[design/codex@main] FilterChip, FilterChipInput: Add WIP components to Codex

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

Change 939386 had a related patch set uploaded (by Jforrester; author: Eric Gardner):

[mediawiki/core@master] Update Codex from v0.14.0 to v0.15.0

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

Change 939386 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v0.14.0 to v0.15.0

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