The closest we have at the moment is ActionField, which has styles for combining text inputs and buttons, and dropdowns and buttons. There is no generic mechanism for combining widgets.

Another thing: how do we deal with longer depicts input?
By default, OOUI's TagMultiselectWidget element expands down. Are we ok with that? If not, what do we want? (and this will probably incur a lot of work...)
And when all elements are in a horizontal layout, this also causes the other elements (dropdown, search icon) to drop slightly since they're middle-aligned (fixing that so that the other elements remain at the top should be a pretty easy override, though)

Given the complexity of this combination of widgets, I would suggest you don't try to make it a single compact widget, and just come up with a way to layout individual widgets that gives you more flexibility.

Another thing: how do we deal with longer depicts input?
By default, OOUI's TagMultiselectWidget element expands down. Are we ok with that? If not, what do we want? (and this will probably incur a lot of work...)
And when all elements are in a horizontal layout, this also causes the other elements (dropdown, search icon) to drop slightly since they're middle-aligned (fixing that so that the other elements remain at the top should be a pretty easy override, though)

Given the complexity of this combination of widgets, I would suggest you don't try to make it a single compact widget, and just come up with a way to layout individual widgets that gives you more flexibility.

What exactly do you mean? Do you suggest we should consider a design where the elements don't appear to be one widget, or that there's a better way to structure/layout all of these widgets (than is currently the case and/or with above CSS hacks)?

@Esanders do you know of any better way we could implement the current design, in a way that doesn't require this many CSS overrides? Or should we look into other solutions?

@matthiasmullie Thanks for bringing this to the surface. We could think of a way to have additional options within the library on putting interface elements together, one thing that immediately comes to my mind though is, how do they behave when they need to be wrapped on smaller screens, non desktop-first environments?

We've had a long discussion about such behaviour in T112982 for comparison.

We haven't had the current use case of clinging several widgets (3+) together apart from just a [input/tag input] and [button] requested by designers yet, so the CSS hacks seem to be the best way to move forward for now.

To your comment of different padding of TextInput- and TagMultiselectWidget placeholder, it comes out of the active contents of those inputs. In order to make inputting a tag seamless interaction the placeholder needed to have that padding.

You could consider not to use a placeholder, but a 'helpInline' label in such case.

Also, why does the search bar need to be 30px height vs 32px, that doesn't seem necessary @PDrouin-WMF?

While on the topic of the search bar: if we're going to have it top-right, replacing the existing search bar, we might want the OOUI elements to be slightly smaller than they are natively. They're currently quite big...
I'm not aware of any existing method of scaling back the size of OOUI elements, so we'd need some unstable CSS overrides if we'd like to accomplish that:

OOUI elements scale with the font size (with the exception of icons, which have a minimal size, for some silly reasons). Can you simply wrap the entire thing in <div style="font-size: 80%;"> or something?

@matthiasmullie Yeah, on the TagMultiselectWidget one, given the left-most widget is variable height I don't think there is a complete design for how this should work as a single widget, so it might be easier to use a design that treats them as separate widgets.