[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 overflow = 'stack' | 'gap' — configure how the group handles overflow into a second row
  • stack — switch to vertical layout when overflowing (used in fieldtype)
  • gap — switch to normal buttons with gaps when overflowing (used in floating toolbar)

Closes #13072 and Closes #14170.

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 overflow = 'stack'
  • Switch between vertical and horizontal layout depending on overflow
  • Other fieldtypes and custom components can use it via <ui-button-group overflow="stack">
• Create a new prop overflow = 'gap'
  • 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 overflow="gap"
  • 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 👍🏼

[daun]

Resolved merge conflicts, deduplicated some styles and updated the readme.

One thing to note: the current default for overflow is undefined, meaning it creates visually unintended states on overflow. I'll leave it up to you guys to decide whether the default should be either gap or stack or if this should require a conscious decision when planning out the UI in each case and stay undefined.

[daun]

@jasonvarga Let me know if there's anything I can do on my end to help move this forward.

[jasonvarga]

One thing to note: the current default for overflow is undefined, meaning it creates visually unintended states on overflow. I'll leave it up to you guys to decide whether the default should be either gap or stack or if this should require a conscious decision when planning out the UI in each case and stay undefined.

It initially made sense to me to make stacked the default, but this makes resize observers for every component. Even for ones where there would be no chance of overflowing.

On a publish form, you may have many fields with field actions that only have one or two buttons. This could result in a lot of added overhead.

Since the button group fieldtype itself opts into stacked overflow, it's not something users will need to worry about.

[daun]

🎉