Personally I think we better darken the hover color instead of making them completely dark.

I agree, this doesn't feel natural to me.

I just pushed some changes which fixed the hover color.

@mdo: WDYT?

Rebased, I need a second look please @MartijnCuppens.

@mermop please do not overwrite the rebase by accident 🙂

Looks good

OK, then we need @mdo @ysds @ffoodd to chime in :)

Already commented on this, I think arguments naming could be more consistent with surroundings.

Apart from that, it's good 🙂

Feel free to rename any args, we can edit the files ourselves unless the user has explicitly turned this off 🙂

Mixin arguments are now consistent —in both naming and order— with previous mixin.

Not in favor of launching v5 alphas with this just yet. It's a pretty strong departure from our current styles and I feel a decent amount of outline buttons roll with this approach. It makes the active state feel out of place somehow.

Looking at https://deploy-preview-28999--twbs-bootstrap.netlify.app/docs/5.0/forms/checks/#outlined-styles i could well go for that (and yes that would solve #31149). not 100% convinced it looks natural for https://deploy-preview-28999--twbs-bootstrap.netlify.app/docs/5.0/components/buttons/#outline-buttons though...maybe do a halfway implementation where this only targets the checkbox/radio buttons (and https://deploy-preview-28999--twbs-bootstrap.netlify.app/docs/5.0/components/buttons/#toggle-states outline ARIA toggles) scenario, but not the regular "one shot" buttons? or does that get too fiddly?

@mdo what's your take on this?

I’m sorry for dropping the ball on the pings here. With the beta phase, do folks consider this a breaking change?

@mdo Yes. If someone used the mixin with named arguments (eg @include button-outline-variant($color-hover: #111), it'll break.

Hi, not sure if this is relevant and not trying to derail -- I can post a separate issue but some similar ones (for mobile, etc.) got marked as dupes, and everything I could find (e.g. #31149) leads to this thread.

I'm on osx desktop chrome 89, and when I click on a toggle state button and mouse away, the focus state is retained, and the current colour choices (in 4.5, 4.6, and 5.0-beta3) for focused/hovered/active make it very hard to tell what the state of the most-recently-clicked button is, until the user clicks elsewhere on the page to dispel the focus-state. Here's a gif from this PR's preview showing a full state-cycle: https://deploy-preview-28999--twbs-bootstrap.netlify.app/docs/5.0/components/buttons/#toggle-states:

You can see after clicking and mousing off, focus is retained and the state looks roughly "active", but much worse is that when toggling off the change is very slight -- it still pretty much looks active, and you have to click somewhere else to know what the state really is.

I ran into this in the wild on arewefastyet.rs today, which starts with some buttons activated that you might naturally turn off -- what is the state of the # of cores component below? With no siblings active, even with other identical active components nearby, it's really tough to tell none were selected until the off-element click.

I actually found their github and cloned their repo just to try to fix this, thinking it was some missing/broken mouseout handler issue, before realizing it's ...just bootstrap's default behaviour+appearance.

If this PR isn't the right place for this or folks don't agree that what I've posted an issue, I'd be happy to re-file/discuss somewhere else.

Would be good to revisit this, as it's been a long-standing issue/problem we've had for aeons now.

When I clicked a button on the example, it works but it flashes the color because the :hover is not opaque enough.

@twbs/css-review any news on this?

My only concern is if we should land this in v5.2.0 (a minor version) or not. It is a potential breaking change, isn't it? If so, is just mentioning in the release notes enough/are we still following semver?

forgot about this PR, and separately did some work here #37026 ... thoughts?

Superseded by #37026.