-
Notifications
You must be signed in to change notification settings - Fork 100
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
fix(global): remove woff, use where with globals, cleanup #5435
Conversation
814fac6
to
9788102
Compare
Preview: https://patternfly-pr-5435.surge.sh A11y report: https://patternfly-pr-5435-a11y.surge.sh |
@srambach that's from removing the
That's to be expected, the old styles were from previous design iterations on buttons. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, looks good then!
Actually though - that primary button doesn't pass the contrast check. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LPTM 🔥
🎉 This PR is included in version 5.0.0-alpha.34 🎉 The release is available on: Your semantic-release bot 📦🚀 |
:where()
around global (normalize and reset) styles. This removes the specificity from these rules, so they will not fight for specificity with any selector styles with a specificity > 0 - from our components or any user overrides.[class*=pf-c-], [class*=pf-c-]::before, [class*=pf-c-]::after { padding/margin: 0; background: transparent; }
, but those were removed for v5 in another PR. However, I think this may be good practice in general for PF and users to be able to easily override any base/global styles without having to fight for specificity or put styles in an appropriate layer (in the future).h1, a, body, etc
and loads PF afterward - our styles will currently override those styles (assuming our specificity is >= and the rules match 1:1), and they will not if we wrap our styles in:where()
. Though I think that kind of conflict is something that should be handled on a case by case basis when importing multiple global styles as there are likely multiple conflicts like that regardless of using:where()