-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
ComboboxControl / FormTokenField: Add flag for larger default size #40746
Conversation
Size Change: +191 B (0%) Total Size: 1.25 MB
ℹ️ View Unchanged
|
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 appreciate this PR is still a draft, but I left a few early comments nonetheless :)
const deprecatedDefaultSize = ( { __next36pxDefaultSize } ) => | ||
! __next36pxDefaultSize && | ||
css` | ||
height: 30px; |
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.
Just to understand — prior to the changes from this PR, is ComboBox
height "computed" from the sum of its intrinsic input height + paddings/borders ?
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.
Yes, and it was wrong 😅 In trunk the height is 29px instead of 30px.
Usually I don't like hardcoding input heights in pixels because it's hostile to users who have a custom font size in set in their browsers, but this repo codes all font sizes in pixel values instead of rems, so... it makes no difference 🙃 Perhaps that ship has sailed.
9d6552f
to
2514e59
Compare
2514e59
to
3cd6112
Compare
const deprecatedDefaultSize = ( { __next36pxDefaultSize } ) => | ||
! __next36pxDefaultSize && | ||
css` | ||
height: 30px; |
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.
Yes, and it was wrong 😅 In trunk the height is 29px instead of 30px.
Usually I don't like hardcoding input heights in pixels because it's hostile to users who have a custom font size in set in their browsers, but this repo codes all font sizes in pixel values instead of rems, so... it makes no difference 🙃 Perhaps that ship has sailed.
@@ -67,7 +63,6 @@ | |||
.components-form-token-field__token { | |||
font-size: $default-font-size; | |||
display: flex; | |||
margin: 2px 4px 2px 0; |
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.
Instead of handling the spacing between tokens with margin
s here, we now use a flex gap on the container (<TokensAndInputWrapper>
). This way the token margins don't mess with the container's paddings.
width: 100%; | ||
margin: 0 0 $grid-unit-10 0; | ||
padding: $grid-unit-05*0.5 $grid-unit-05; |
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.
We're refactoring this padding so it's handled by a subcontainer that doesn't contain the suggestions list (<TokensAndInputWrapper>
). This allows us to remove the awkward negative margins on .components-form-token-field__suggestions-list
that were needed to break out of that padding.
const deprecatedPaddings = ( { | ||
__next36pxDefaultSize, | ||
hasTokens, | ||
}: TokensAndInputWrapperProps ) => | ||
! __next36pxDefaultSize && | ||
css` | ||
padding-top: ${ space( hasTokens ? 1 : 0.5 ) }; | ||
padding-bottom: ${ space( hasTokens ? 1 : 0.5 ) }; | ||
`; |
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.
In trunk, the input height increases a bit when you commit a token. I'm keeping this behavior for now in the deprecated case, but in the 36px case there won't be anymore height jumps.
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.
Sounds like a sensible approach
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.
Great work here!
I noticed that the new version of the Combobox
is taller than its version on trunk
. The element wrapping the input has an overall height of 32px
(30px
height, plus 1px
of border top and bottom)
combobox-height.mp4
Is this expected? For example, I had a look at InputControl
, which seems to have an overall height
of 30px
(and uses an absolutely-positioned backdrop to render a border).
Similarly, in the 36px
version of the component, the overall input's height is effectively 38px
once we consider the border.
export const TokensAndInputWrapper = styled.div` | ||
display: flex; | ||
flex-wrap: wrap; | ||
align-items: center; | ||
gap: ${ space( 1 ) }; |
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.
Is there any reason why you prefer CSS styles to using the Flex
and HStack
components?
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.
Lol I forgot that existed! Replaced in 7e411f1.
I noticed that <Flex>
does some magical margin
computations under the hood to replicate gap
in older browsers. Maybe we can remove that soon now that Safari is compliant.
const deprecatedPaddings = ( { | ||
__next36pxDefaultSize, | ||
hasTokens, | ||
}: TokensAndInputWrapperProps ) => | ||
! __next36pxDefaultSize && | ||
css` | ||
padding-top: ${ space( hasTokens ? 1 : 0.5 ) }; | ||
padding-bottom: ${ space( hasTokens ? 1 : 0.5 ) }; | ||
`; |
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.
Sounds like a sensible approach
Totally forgot to fix that, thanks for the catch! |
Just to note: Although we're pausing active work on #39397, I'd like to land this PR since the work is already done, and it includes some nice element refactoring that might also help us when adding the 40px variants. |
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.
- ✅ All feedback addressed
- ✅ Input fields have the correct height (
30px
,36px
) - ✅ Tests well in Storybook
🚀
Added the Needs Dev Note label in case this needs a dev note (either individual or as part of a "misc" dev note) for WP 6.1 release. |
@mirka probably we should write a general dev note for the margin work that you've been doing? |
Yes, I've been tagging my margin PRs that involve actual deprecations, so we'll definitely have a Dev Note about those. For this specific PR though, |
Part of #39397
What?
Adds the temporary prop
__next36pxDefaultSize
to opt into the new 36px height default size.Why?
As part of the effort to move toward consistent component sizes.
This PR had to include two components at once because
ComboboxControl
depends on someFormTokenField
subcomponents internally.How?
See inline comments for notable points.
Testing Instructions
npm run storybook:dev
ComboboxControl
andFormTokenField
. They should look nice with the__next36pxDefaultSize
prop enabled. With the prop disabled, it should look the same as in trunk (ComboboxControl, FormTokenField).FormTokenField
, also test the case where there are a lot of tokens and it wraps to the next line.Known issues
I imagine we'll want to make the paddings in the suggestion list roomier to match the larger input size, but I'll leave that to a future PR.