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

InputControl: Decrease large default padding if has prefix/suffix #42166

Merged
merged 8 commits into from
Jul 14, 2022

Conversation

mirka
Copy link
Member

@mirka mirka commented Jul 5, 2022

What?

Ensures that the padding between the prefix/suffix and the text input doesn't get too big in the large size variant of the component.

Why?

The large size variant of the component increases the side paddings of the text input to 16px (previously 8px). In most cases, this is too big when using with a prefix or suffix element. Some actual examples of this can be seen in the large variants of UnitControl and ColorPicker:

Paddings in the UnitControl component

Paddings in the hex input of a ColorPicker component

How?

Added an internal API to specify custom side padding on the InputField subcomponent. This API is internal-only for now, and is meant to minimally satisfy the internal customization needs in the components library. Though, I tried to make it generic enough so it would be easy to expose the API externally on InputControl itself, if we want to do so in the future.

Testing Instructions

  1. npm run storybook:dev
  2. Check the "With Prefix" and "With Suffix" stories for the InputControl component. The padding between the prefix/suffix and the text input should remain at 8px, regardless of the size variant. This should also work in RTL mode.
  3. Check the stories for UnitControl. There should be no regression in padding between the text input and the unit dropdown.

Screenshots or screencast

Before After
Large size InputControl with a prefix, 16px padding in between Large size InputControl with a prefix, 8px padding in between

@mirka mirka added the [Package] Components /packages/components label Jul 5, 2022
@mirka mirka self-assigned this Jul 5, 2022
@mirka mirka requested a review from ajitbohra as a code owner July 5, 2022 17:53
Comment on lines +43 to +49
prefix: <span style={ { marginInlineStart: 8 } }>@</span>,
};

export const WithSuffix = Template.bind( {} );
WithSuffix.args = {
...Default.args,
suffix: <button style={ { marginRight: 4 } }>Send</button>,
suffix: <button style={ { marginInlineEnd: 4 } }>Send</button>,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tweaked examples for better RTL.

@@ -18,22 +18,13 @@ type SelectProps = {

type InputProps = {
disableUnits?: boolean;
size: SelectSize;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelated, but minor cleanup of an unused type.

Comment on lines -29 to -36
const paddingStyles = ( { disableUnits }: InputProps ) => {
if ( disableUnits ) return '';

return css`
${ rtl( { paddingRight: 8 } )() };
`;
};

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CSS override removed 🎉

Btw @aaronrobertshaw: When building BorderControl, do you remember if there were any blockers to rendering the BorderControlDropdown as a prefix on the UnitControl? I'm wondering if we can remove some CSS overrides in there too if this PR lands.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My memory is failing me on this one, I don't recall any blockers. It might have been as simple as I didn't see the prefix prop in the UnitControl readme and didn't follow the props through to the underlying InputControl.

It also looks like we might need to tweak the UnitControl types, as attempting to pass the border control dropdown via a prefix prop on the UnitControl results in a type error that it expects prefix to be string | undefined.

I'd be happy to work on rendering the border control's dropdown as a prefix in a follow up to this PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds great, thanks! It's nice to see things getting less hacky as we converge on common patterns 🙂

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've put together a PR (#42212) that now renders the dropdown via the UnitControl prefix and attempts to clean up the styles. There could still be more to polish on that control when it comes time to add a large 40px size variant.

Copy link
Contributor

@ciampo ciampo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just left a couple of comments related more to the implementation details of these changes, but the overall direction of the PR looks good, and the changes test well in Storybook!

Copy link
Contributor

@aaronrobertshaw aaronrobertshaw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking good and tests well for me 👍

✅ With Prefix/Suffix stories maintain 8px padding regardless of size variant
✅ Padding functions consistently when in RTL mode
✅ No regressions for UnitControl in Storybook
✅ UnitControl tests pass

@jameskoster
Copy link
Contributor

Seems to be working as expected, though ideally we should increase the margin/padding on the prefix/suffix as well, so that it matches the input:

Screenshot 2022-07-06 at 10 11 15

@mirka
Copy link
Member Author

mirka commented Jul 6, 2022

ideally we should increase the margin/padding on the prefix/suffix as well

Currently InputControl doesn't add any left padding to the prefix, instead leaving it to the prefix element itself to handle it. I believe this is because sometimes the prefix/suffix elements need to be flush with the text field.

But I agree that it's kind of necessary that the prefix/suffix elements know what the standard padding is for a given size variant. As a follow-up task, I'll see if I can propose something where InputControl provides the prefix component with a paddingInlineStart prop so the prefix can use that padding value for styling if they want.

Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>
@mirka
Copy link
Member Author

mirka commented Jul 12, 2022

But I agree that it's kind of necessary that the prefix/suffix elements know what the standard padding is for a given size variant. As a follow-up task, I'll see if I can propose something where InputControl provides the prefix component with a paddingInlineStart prop so the prefix can use that padding value for styling if they want.

Solution proposed in #42378 👍

This PR can proceed independently of that PR though.

@ciampo ciampo added [Type] Enhancement A suggestion for improvement. [Feature] UI Components Impacts or related to the UI component system labels Jul 14, 2022
Copy link
Contributor

@ciampo ciampo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given previous conversations and the follow-up already opened in #42378, I believe we can go ahead and merge this one 🚀

@mirka mirka merged commit a979537 into trunk Jul 14, 2022
@mirka mirka deleted the fix/input-prefix-suffix-padding branch July 14, 2022 22:25
@github-actions github-actions bot added this to the Gutenberg 13.8 milestone Jul 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] UI Components Impacts or related to the UI component system [Package] Components /packages/components [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants