I have built a multi-select dropdown with a search field that becomes visible on focus. However, when an element is already selected in the multi-select input, the search field has to be render on a new line and this makes the whole element taller. This slightly pushes all below elements downwards.

My client thinks this is a bad user experience but I believe it is acceptable because the search input has to go somewhere. What is your opinion?

Before focus

Rows of multi-select dropdowns. enter image description here

On focus

Red arrows indicate the increased gap caused by the increase in heights of the focused multi-select dropdown. enter image description here

  • 2
    If the multiple select options are overlapping the rows below, why can't the search input overlap also? Feb 7 at 18:40
  • 1
    Ideally, the layout shouldn't change like that but there could be lots of reasons why you need to make it happen that way. What is the purpose of the search field and why does it need to be there? Is it for searching for tags like the 'Worker" tag directly above it? If so then what is the icon to the right of the tag? I wonder if you're trying to solve the wrong problem by expanding the row Feb 7 at 20:06
  • @RouxMartin yes, it is for searching for objects like Worker. The hamburger icon on the rights symbolises that there you can click the whole area to see the dropdown. Feb 8 at 11:24
  • 2
    In that case, I'd suggest that clicking the icon opens an overlay menu or a modal rather than trying to force the user to complete that operation within the table cell Feb 8 at 13:40

2 Answers 2


This behavior will almost definitely be perceived as a bug. The object you spawn either sits on top of the existing content in some form (like a piece of paper), or it's part of the list and thus constrained to the table. If it needs to expand, the entire table row would expand with it.

Or in visual terms, if you have this:

a list with options

the expected behavior when clicking the options icon of the first menu item is either of the following: variant 1: expand the cell to fit all options. variant 2: overlay options, including the item inside the overlay. Variant 3: overlay options, not including original item

  • Great answer. Can you address the specific issue that only the SEARCH input sits in the same layer as the content (ITEMS), while only the OPTIONS are in the top layer? Feb 23 at 10:36
  • In your specific example, the search input does not sit in the same layer as the content. From a technical standpoint it may, but the entire object surrounded by the blue border is perceived as one floating object which is anchored to the page at the list-icon button. If you want to have search as part of the table, it would need to live outside the blue border, at which point you'd lose the connection between what it's actually searching. Feb 24 at 13:30

I think the Law/Principle of Common Region kicks in here.

As the search input is part of the combo box, and the combo box is overlapping contents, it should not take up space that is lying "behind" itself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.