Chip

There was a long stretch where the values a user picked never stayed on screen. A list would have three select menus above it, the user would choose one option in each, and the list would filter down. A select collapses again after you choose, so the only thing left visible was the filtered result.

Which produced this: someone opens the document list expecting around 2,000 items and finds 3. They assume the list is broken, so they refresh. Still 3, so they log out and back in. Nothing was broken — a condition they set last week was still applied. It was sitting inside a collapsed select, invisible until opened.

A chip solves that with layout rather than logic. Lay the chosen values out as pills directly above the list and the user can read what's applied without opening anything. Removing a condition ends in the same place: instead of reopening the select and unchecking a box, you click the small x on the right of the pill. Putting the display and the removal into one object is the whole idea behind the component.

One chip stands for one value, and clicking it either changes that value or removes it. It looks like a simple pill, but four things go inside.

1. The label. The value written out as text — Marketing team, exactly as the user chose it. This is the one place not to truncate. A label cut down to Marketi… leaves the user unable to tell which condition they are about to delete.
2. The state. Whether this value is currently on or off, expressed through background color or border. In a row of selectable chips, unselected ones usually carry only an outline while selected ones get a filled background.
3. The remove button. A small x to the right of the label. Only chips that represent an already-applied value carry one; chips still being chosen from do not.
4. An icon. Optional, placed left of the label. A chip standing for a person often leads with an avatar so the face identifies the value faster than the name does.

The awkward part is that one chip contains two clickable areas. The body opens an edit view and the x deletes the value, and both sit inside a space about a fingertip wide. A touch target is the minimum area reserved for a finger, usually taken as 44 pixels, and a chip only 32 pixels tall leaves its x smaller than that. This is where a user aiming to delete ends up in an edit screen instead. On mobile it's safer to drop the x entirely and make the whole chip removable on tap.

Growth in count needs a rule decided up front, too. Twelve applied conditions turn into three rows of chips and push the actual list off screen. Deciding that two rows show and the rest collapse into a +9 keeps that from happening.

The shape stays the same across three fairly different jobs.

Showing applied conditions is the most common one. The filters currently in effect sit in a row above the list, each with an x so it can be dropped individually. The three-results problem above disappears with that one row. It also changes how people narrow a search: with the conditions visible, someone who over-filtered can drop one and watch the count climb back, instead of clearing everything and starting the whole selection again.

Multi-select inputs use chips as well. Ten checkbox options stacked vertically eat half a screen; the same ten as chips fit in two rows. The tradeoff is that chips have no checkmark, so selection is signalled by color alone. Color alone carries nothing to someone who has trouble distinguishing it, which is why adding a check icon to selected chips counts as baseline accessibility work here.

Free-form tag entry is the third. The user types into a text input and a comma or enter key freezes the text into a chip. Email recipient fields behave this way. Once frozen, the value is an object rather than characters, so one backspace removes one whole recipient. With ten addresses entered and only the third needing to go, plain text means hunting between commas with a cursor; chips mean clicking that one.

"Pull the applied filters out as chips. Right now you can't see what's on."

A request to move conditions out of a collapsed control and onto the screen above the list.

"That's a badge, not a chip. There's nothing to click."

Similar shape, but a non-interactive marker should use a different component.

"Twelve chips makes three rows — should we show two and collapse the rest?"

A proposal to settle the overflow rule before the count grows.

At Pagedeck this came up the week filters landed on the document list. Noa's first version put three selects side by side, and three days after release a support ticket arrived saying documents had disappeared. The conditions from the user's previous session were still applied.

Noa added a row of chips beneath the selects, each with an x. Theo's question was about volume: what happens with twenty teams and forty tags all applied. They settled on two visible rows with the remainder collapsed into a +12. Mia asked that clicking the collapsed chip expand the rest rather than open the select, since someone who came to see what was applied shouldn't be dropped into an editing view. The version that shipped kept the selects as the place to add conditions and the chips as the place to read and remove them, which turned out to be the split users expected.

The most frequent mistake is reading a chip as a small button. Rounded corners, responds to clicks — the resemblance is real. But a button runs an action and a chip represents a value. Save is a button; Marketing team is a chip. Blur that and a row ends up holding Draft, Shared and Export in identical shapes, and users click the first two expecting something to happen.

Assuming every chip can be dismissed is the other one. Filter chips carry an x, so the x starts to feel like part of the shape. Display-only chips don't have one. When a team styles a read-only chip exactly like a filter chip, users hunt for the x, then click the body, then decide the screen has frozen when nothing responds. A value that can't be acted on belongs in a badge instead.