Differentiate hover state for outline buttons

[mermop]

The :hover state for outline buttons is effectively the same as the :active state, so it can be difficult to tell the difference between a button that is hovered over and one that is active - particularly when using eg checkbox/radio buttons as buttons, which uses the active class to show that something is selected.

This change adds $hover-background and $hover-border as options to the button-outline-variant mixin, and gives them default values half-way between than the $color and white.

I think this is related to #26804

Current state

With change

Closes #26804

Preview: https://deploy-preview-28999--twbs-bootstrap.netlify.com/docs/5.1/components/buttons/#outline-buttons

[MartijnCuppens]

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

[XhmikosR]

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

[MartijnCuppens]

I just pushed some changes which fixed the hover color.

[MartijnCuppens]

I like this

[XhmikosR]

@mdo: WDYT?

[XhmikosR]

Rebased, I need a second look please @MartijnCuppens.

@mermop please do not overwrite the rebase by accident 🙂

[MartijnCuppens]

Looks good

[XhmikosR]

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

[ffoodd]

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

Apart from that, it's good 🙂

[XhmikosR]

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

[ffoodd]

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

[mdo]

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.

[patrickhlauke]

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?

[XhmikosR]

@mdo what's your take on this?

See Mark's comment

[mdo]

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

[ffoodd]

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

[wcarss]

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.

[patrickhlauke]

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

[shivamCode0]

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

[GeoSot]

@twbs/css-review any news on this?

[ffoodd]

I'm still up for this, however this is for a minor release and should be highlighted in the changelog as a potential BC.

[XhmikosR]

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?

[patrickhlauke]

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

[mdo]

Superseded by #37026.