@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

Proposed

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. 🙃

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?

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

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.

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.

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

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.

: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 .