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(form-control): move borders to pseudo element, remove extra css #5641
Conversation
Preview: https://patternfly-pr-5641.surge.sh A11y report: https://patternfly-pr-5641-a11y.surge.sh |
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.
🎉
--#{$form-control}--after--BorderRightWidth: var(--#{$pf-global}--BorderWidth--sm); | ||
--#{$form-control}--after--BorderBottomWidth: var(--#{$pf-global}--BorderWidth--sm); | ||
--#{$form-control}--after--BorderLeftWidth: var(--#{$pf-global}--BorderWidth--sm); | ||
--#{$form-control}--after--BorderWidth: var(--#{$pf-global}--BorderWidth--sm); |
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.
One small thing, doesn't look like this after--BorderWidth
var is being used anywhere
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.
Generally this looks good but for a few nits and the focus ring question.
Also, just for discussion - using --after
is consistent with our model, but when I was refactoring the cards we talked about using more logical names to keep future things non-breaking and perhaps ease token use. E.g., if we kept the border variables as is, we could move them between the wrapper or the pseudo-element or whatever clever thing we came up with, without causing a breaking change. WDYT?
} | ||
} | ||
|
||
&:hover { | ||
--#{$form-control}--BorderBottomColor: var(--#{$form-control}--hover--BorderBottomColor); | ||
--#{$form-control}--after--after--BorderBottomColor: var(--#{$form-control}--hover--after--BorderBottomColor); |
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.
Search and replace oops? (--after--after)
@srambach thanks for the review! Should have addressed everything but the focus ring. Dark theme vars also needed to be updated, moved the Re: the focus ring... a few thoughts. I'll note that from glancing, the focus ring looks the same in menu toggle and control buttons, which have the same look.
|
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.
I think moving the borders to a pseudo is a good idea, but typically we add gray, static borders to ::before
and accent/hover borders to ::after
to avoid bevelled borders
I don't hate moving the outline-offset in about 2px. That gives the full focus ring, the width is consistent with other focus rings other than the ones you mention (which then could be updated as well), and still shows the status bottom border color. Do you know of any problems it creates? |
Co-authored-by: Matt Nolting <matthew.nolting@gmail.com>
Co-authored-by: Matt Nolting <matthew.nolting@gmail.com>
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.
👍
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.
Thanks for updating, LPTM!!
🎉 This PR is included in version 5.0.0-alpha.75 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Updates the form control to move the borders to pseudo elements, remove all of the custom height and padding
calc()
s that were needed to offset the borders since they were part of the component layout.