Bootstrap 6 feedback

[mdo]

We’re quietly chipping away at Bootstrap 6’s development and would love feedback as we go. Using this discussion to help consolidate feedback outside our issues for now, and keeping it more informal now. My only request is that folks create threads as they go to ask specific questions, share ideas, etc. and use reactions/replies to add their voice to the mix.

Preview the auto-updating v6 docs here.

The branch is v6-dev and we’ll continue there for the foreseeable future until we hit a new stable release. Expect alphas, betas, and then an initial release.

<3

[pricop]

@mdo as per #42061 I'm opening a thread here instead.

Here's my feedback, with a table representation, a visual representation, as well as live demo links:

Table representation:

Current

Variant	input-height	button-height	input-font-size	button-font-size
lg	53px	44px	17.5px	16px
md	40px	36px	14px	14px
sm	32px	32px	12.25px	14px

Proposed

Variant	input-height	button-height	input-font-size	button-font-size
lg	44px	44px	18px	18px
md	38px	38px	16px	16px
sm	32px	32px	14px	14px

Visual:

Live:

Current version example at: https://codepen.io/pricop/pen/XJKvGob
Proposed version example at: https://codepen.io/pricop/pen/LEZwvPL

Personally, I feel like working with 1rem set to 16px is much easier to keep everything consistent, screens are getting larger every year, so sizing shouldn't be an issue.

As a side note, I know these examples won't be for web, but could be used as a reference:

iOS defaults to 17pt for body text, inputs, and buttons. Labels are 15pt (small).
Android defaults to 16pt for body text, inputs, and buttons. Labels are 14pt in size (small).
macOS26 has enlarged pretty much all UI buttons inside app windows.

I know BS is a web framework, and must cather to a plethora of web apps, including those with complex dashboards, but I've always felt that applying "small" is much easier to implement, than resetting the font-size to be larger, as it requires adjusting paddings and margins all over the place, and both BS4, and BS5 handled this very nicely.

Going from 16px on a component, to a 14px on a component doesn't require many (if any at all) changes to margins/paddings. While going from 14px to 16px will require way more changes.

And something to really consider, if you still want to go with the 14px route for -md inputs & buttons:

• Use 14px for -md buttons and inputs, with larger padding that would equal a 36px height for -md variants.
• Keep the existing -sm variants as they are, only with an increased 14px font size for the inputs.

Feel free to mention me whenever you make a design decision on this, I'd be more than happy to offer feedback on it. 🙃

[pricop]

If the decision is to go with 14px for the regular components, my suggestion would be to make the -md input's height always match the button's height, here's how it would look like live: https://codepen.io/pricop/pen/gbwYOqe

Basically, both -sm and regular variants will share the same font-size, but the -sm variant will have smaller paddings (which is what BS6 already does for the -sm button anyways, so just the input's font-size will need adjustments).

[davidm49090]

I'm excited that chips will be a forms component for 6.0. Would it be possible to make the rounding optional so that they present more like form buttons?

[pricop]

That's already possible by customizing $chip-border-radius variable. Furthermore, you can also quickly style it using any of the border-radius utilities.

[davidm49090]

Thank you for clarifying!

[mdo]

Yup, there will be a CSS variable to easily override here (which will also be customizable via Sass).

[anvme]

Hello!
I'm a fan of Bootstrap! Use it in all my projects from 2015, I think, maybe earlier

Of course, with some help of llm, I created a set of components which can be replaced with native browser api, which was already done on the modal on v6

In fact, this gives many benefits. I'd like to share this set for v6 improvements with you. Also added some new features for docs, I'd like to see

So, my proposal/feedback is here https://anvme.github.io/v6-proposal/ this reduce js + speed up components/websites

[mdo]

Wow, this is really amazing. I'll look into this more soon! If you have specific, surgical updates we can make to JS plugins, you can also draft something out—maybe not a full PR because I don't want you to waste time—but an issue to plan a change for one component maybe. Up to you!

[brianroadifer]

I was looking at some of the new docs for the Form elements and I noticed the use of using unregistered custom HTML tags for the grouping of labels with the updated .check and .radio. This being in regards about .form-check being replaced by b-checkgroup and b-radiogroup.

Wouldn't this run into issues if a custom HTML element is registered with a matching tag and unexpected behavior occurred?

I've been following a bit of the development of v6 and there isn't anything suggesting that Bootstrap will adopt the use of custom HTML elements to make components. Without registering this HTML tag, it will be a rather direct hack rather than a clean use of CSS+JS that Bootstrap is well known for.

[mdo]

I'm hyped on web components (initializing with JS) and custom elements (just random strings as HTML elements), and these components are stuck in between. I was just talking with @julien-deramond about how we could improve these. I think for v6.0.0, we'll see these custom elements replaced with standard markup and web components or custom elements could be added down the line.

[anvme]

Also, some automated reports over the source code of Bootstrap v6:
ESLint: https://anvme.github.io/v6-proposal/eslint-report.html
ast-grep: https://anvme.github.io/v6-proposal/astgrep-report.html
Stylelint: https://anvme.github.io/v6-proposal/stylelint-report.html
jscpd: https://anvme.github.io/v6-proposal/jscpd-report.html

UPD: 27 Feb
Auto Updated reports available at https://anvme.github.io/bt-v6-tests/

[julien-deramond]

Thanks for reporting @martinbean 🙏
FYI, the homepage hasn't been revamped yet by @mdo. There are a lot of tiny rendering issues in the docs right now, but I'm adding this one to my list :)

[mdo]

This specific issue has been resolved.

[kminek]

i think v6 should give some more love to responsive <table>. tables are bread & butter in typical CRUD apps where Boostrap is frequently used. if table is wide (many columns) horizontal scrollbar is of course nice but experience could be improved on mobile devices - maybe something like "stacked table" where cells stack vertically on top of each other and column titles are pulled from data- attributes.

[martinbean]

I think one quality of life improvement would be a “sticky” column: where if you have a column that’s acting as headers, and you horizontally scrolling the table body, then that headers column stays static.

Think league tables in sports where the first column is usually the team name, and you’re scrolling statistics such as games played, goals, goal difference, points, etc. Those statistics then lose context if you can no longer see which team they’re related to.

Example: go to https://www.bbc.co.uk/sport/football/tables, shrink your browser’s width, and then horizontally scroll the league table.

[anvme]

v6 docs problems:

1. Page https://v6-dev--twbs-bootstrap.netlify.app/docs/6.0/examples/ [Dialogs] dialogs@2x.png or dialogs.png - links to image is giving 404. so card is broken
2. Datepicker: floating calendar not hidden on mobile (390px)

Page: https://v6-dev--twbs-bootstrap.netlify.app/docs/6.0/forms/datepicker at Mobile view on iPhone for example

What fails

Section	ID	Blocked by
Date range	#datepicker4	Stuck popup from Multiple months (#datepickerMultiMonth)
First day of week	#datepicker6	Stuck popup from Multi-month date range (#datepickerRangeTwoMonths)

Bug

Closing a datepicker sets data-vc-calendar-hidden on the floating .vc element but it stays display: flex at full height. Popups accumulate in <body> on every open/close.

Multi-month popups are 538–572px tall on a 390px screen — they cover the next input below.

Reproduce

1. Open datepicker page at 390px width
2. Click Multiple months (#datepickerMultiMonth)
3. Press Escape — popup stays visible (572px tall, display: flex)
4. Try clicking Date range (#datepicker4) — blocked by the stuck popup

Root cause

Missing CSS rule:

.vc[data-vc-calendar-hidden] { display: none; }

The .hide() JS API has the same issue — sets the attribute, element stays rendered.

Works fine on desktop — popups don't overlap next inputs at wider viewports.

[julien-deramond]

Thanks for reporting these issues @anvme 🙏
FYI, The 404 error regarding dialogs images will be fixed in #42099

[7999999166]

:root {
--bs-primary: oklch(62% 0.25 29);
}

will affect:

✅ .bg-primary
✅ .text-primary
✅ .btn-primary
✅ Hover state
✅ Active state
✅ Subtle background
✅ Borders
✅ Outline buttons

All automatically. ? , if this is the case , this will be huge .

[mdo]

Yes, if you update the root --bs-primary-* tokens, anything consuming that variable will be updated. So setting --bs-primary-bg to --bs-orange-500 would change from blue to orange for buttons and more. You'd want to update all those theme tokens at once, either in our Sass map or manually in your custom CSS. More info is at https://v6-dev--twbs-bootstrap.netlify.app/docs/6.0/customize/theme/.

[mdo]

Quick update to everyone here—I've started to address much of the feedback here. Because GH Discussions are a little limited, I've also made a new discussions section called v6 Feedback, where this thread now lives. This way we can all make new threads instead of piling on replies here. See https://github.com/orgs/twbs/discussions/categories/v6-feedback.

Since this thread opened, I've updated a lot of documentation (especially on theming and Sass), fixed some docs design issues, restored 16px base font size, and shipped a brand new method of customizing Bootstrap with a CSS variable based Sass token map. Check out the Sass docs page for more info.

[pricop]

Thank you, it looks way nicer with 16px as the base font size. I'll be submitting feedback soon on the new discussions category.

[crdo]

Hi Mark, great to see the v6 traction, I was getting nervous already (lol).
As we are introducing a new button size, I think we should have better api/styles for spinners inside various button sizes.

My opinion is that a spinner inside each button size should automatically adjust from the size perspective so it is balanced with its surroundings, or there should be a spinner size for each respective button size.

This is a quick demo of each button size with small spinner - and I do not think this is good enough.

[mdo]

Haha, negative padding and gaps have to go—this is a bug after I introduced negative margins quite lazily.

[Super-Kenil]

Need a hand with anything?

[crdo]

I really like the idea of Nav overflows. That is something I needed to manually deal with on many projects.
I think it would be really helpful if we could use this for group of buttons too.
UI use case reference attached.

[martinbean]

https://github.com/orgs/twbs/discussions/42090#discussioncomment-16015773:

we can all make new threads instead of piling on replies here. See https://github.com/orgs/twbs/discussions/categories/v6-feedback

[crdo]

Did not get that. Thanks.

[pricop]

He meant you should open a separate Thread with your Feedback, instead of replying to the current one, by using this link instead: https://github.com/orgs/twbs/discussions/categories/v6-feedback - much easier to see and manage. Your idea is great, but it might not be seen here.