Replace .btn-block with utilities

[mdo]

This now replaces .btn-block with .d-grid and .gap-* utilities. This enables responsive behaviors for the former .btn-block, while also making it much more customizable for responsive behaviors and more.

---

Moves .btn-block from a .btn modifier class to a parent wrapper, allowing us to more easily manipulate a group of buttons. For folks who want an individual button to be "block level", adding w-100 basically accomplishes that. This now makes it possible for a group of buttons to start off stacked and then go inline once a breakpoint is reached.

Unlike most of our responsive classes, these are built with media-breakpoint-down(), so they use max-width instead of min-width in their media queries. Anecdotally, this fits the pattern of responsiveness for a group of buttons—you stack them on narrow viewports and expand them into a single line when there's available space.

I think I need to take another pass at the copy in the docs still. Beyond that, I'm also considering changing this to .btn-stack or something similar. If we did that, we might be able to backport this to v4 as a new feature in v4.6.0. Thoughts?

Preview: https://deploy-preview-31995--twbs-bootstrap.netlify.app/docs/5.0/components/buttons/#block-buttons

[voltaek]

Is your intention with not applying any styling to the non-stacked buttons for utilities to get utilized for customization without having to fight built-in styling? For example, I could see wanting to always have the non-stacked buttons grow horizontally to fill their container (so whitespace is more consistent between stacked and not), but if we made that the default behavior and someone has a different idea for how they want the non-stacked buttons to work, then they'd have to use utilities to first fight that default behavior instead of just applying their own straight-away.

[MartijnCuppens]

Not convinced of using this approach

• Using CSS grid might be a little better instead of the + .btn approach, see https://codepen.io/MartijnCuppens/pen/JjKvxbV
• Using .btn-block for a wrapper feels weird. In other BS components, the part after the dash indicates a modifier or a subcomponent while this is a wrapper.
• The media-breakpoint-down implementation might also be a little confusing, since we use breakpoint modifiers in other components thee other way around.
• I prefer to split layouting CSS from component CSS. Maybe we could have a look if we could add some flexibility to the grid PR which takes care of cases like these?

[mdo]

Do we leave this as custom CSS then, or provide helpers/utilities to enable those kind of layouts? See my comment at #32034 (comment) for something I've been thinking about since seeing that issue and another OSS project.

[mdo]

@MartijnCuppens Could we do something like this when #32066 ships? https://codepen.io/emdeoh/pen/zYBLbOM Wondering how to handle a .gap utility alongside the .g* utilities... just need a way to consume those CSS vars we have.

[MartijnCuppens]

We can't combine the gap & gutter utilities (yet), since some browsers don't support flex gap yet (https://caniuse.com/flexbox-gap).

But we can indeed introduce new .gap-* utilities like this, I don't think we'll need additional CSS custom properties here: https://codepen.io/MartijnCuppens/pen/xxOawYK?editors=1100

[mdo]

@MartijnCuppens This is now completely revamped to use .d-grid and .gap classes, so no more .btn-block classes of any kind. Migration guide was updated, as were the button docs showing the examples.