Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buttons bug #37115

Closed
3 tasks done
govorov-top opened this issue Sep 9, 2022 · 4 comments · Fixed by #37165
Closed
3 tasks done

Buttons bug #37115

govorov-top opened this issue Sep 9, 2022 · 4 comments · Fixed by #37165
Labels

Comments

@govorov-top
Copy link

govorov-top commented Sep 9, 2022

Prerequisites

Describe the issue

Buttons
Added a transparent default hover border color CSS variable for buttons to fix a visual regression

Update 5.2.1 came out. In our projects after the transition to this version, all the buttons are broken.
I think that the promblem is in the component @import "bootstrap/scss/buttons";

In version 5.2.0 it was like this:

Screenshot_1

In version 5.2.1 it is like this:

Screenshot_2

Which overrides all styles and breaks the layout and logic.
Screenshot_3

Reduced test cases

Exemple: https://codepen.io/rgameshow/pen/zYjqoRK

What operating system(s) are you seeing the problem on?

Windows, macOS, Android, iOS, Linux

What browser(s) are you seeing the problem on?

Chrome, Safari, Firefox, Microsoft Edge, Opera

What version of Bootstrap are you using?

5.2.1

@space900

This comment was marked as duplicate.

@lucifer694u

This comment was marked as spam.

@lildeadprince
Copy link

Not sure how what stands for a "breaking change" in CSS community, but from my point of view changing the specificity of a selector to a more specific one is maybe not a "major", but indeed is breaking.
(And looking into issues tab, that's probably not the only one example in 5.2.1)

Of course we always take SemVer with a grain of salt in web development, but I wouldn't expect such changes in patch (*.*.X) release.
I'd say such changes must be released only under a feature (*.X.0) version bump.

@patrickhlauke
Copy link
Member

from my point of view changing the specificity of a selector to a more specific one is maybe not a "major", but indeed is breaking

in hindsight, sure. we just didn't catch the implications for people who then customise things on top in that particular way. we're only human, so no need for a big discussion on SemVer ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

6 participants