[6.x] Bring back responsive button groups

[daun]

Somewhere on the way to v6, auto-stacking button groups went away. This PR brings them back and allows control over the behavior when buttons wrap to a second line:

• New prop orientation="auto" — switch to vertical layout when overflowing (used in fieldtype)
• New prop gap="auto" — switch to normal buttons with gaps when overflowing (used in floating toolbar)
• Maybe this should be a single prop? overflow = 'stack' | 'gap'

Closes #13072.

Button Group Fieldtype

Floating Toolbar

Required changes

• Move the auto-stacking behavior into the button group component, and out of the button group fieldtype
• Create a new prop orientation
  • When set to auto, it will switch between vertical and horizontal layout depending on overflow
  • Other fieldtypes and custom components can use it via <ui-button-group orientation="auto">
• Create a new prop gap
  • When set to auto, it will switch between gaps and no gaps between buttons depending on overflow
  • This completely replaces the [data-floating-toolbar] special case since that's now just gap="auto"
  • It also makes the floating toolbar completely responsive without hardcoded breakpoints
• Switch component to cva because of the inherent complexity

[andjsch]

Wouldn't it be better if the group fieldtype behaved the same way as the floating toolbar buttons? So instead of stacking and taking up more space, separating the buttons with some padding…

I know it stacked in v5, but I think it's not the best solution as it takes up quite more space than it needs to.

[daun]

@andjsch I'd disagree. A gap between button group items would no longer communicate the nature of the input: it's basically a three-way toggle. You have to pick exactly one. Putting them in a single parent element with a common border shows that clearly.

The floating toolbar on the other hand is a collection of actions. They're not exclusive, and not even strictly related in their function. So it doesn't have the constraint of having to show exclusivity.

The distinction becomes clearer when removing the text. I've been working on icon-only versions of button groups lately. To differentiate an icon group (choose one) from icon toggles/checkboxes (choose any number), the gap/no-gap distinction is quite crucial.

If anything, I think that'd be an argument for introducing gaps in the floating toolbar at all sizes?

[andjsch]

Good points. Agreed 👍🏼