-
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
Components: Add opt-in prop for 40px default size for BoxControl
, BorderControl
, and BorderBoxControl
#56185
Conversation
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 see why using the __next40pxDefaultSize
to force size
to __unstable-large
makes sense for this PR, since it keeps code changes to a minimum. We will be able to clean up this code after deprecating/removing both the __next40pxDefaultSize
prop, and the __unstable-large
value for the size
prop (see logistics)
When both __next40pxDefaultSize
and isCompact
are true
, BorderControl
is not wide enough to show the border width:
Not related to this PR (since it can be observed on trunk
too), but I realised the BorderControl
's dropdown toggle size looks off:
This is probably due to some updates to other components that caused the height of the unit control and the toggle to go out of sync — the 30px
width/height specified here should be updated:
- the simplest update would be to change
30px
to32px
- it would also be tempting to remove those hardcoded values altogether, and use the
size
and__next40pxDefaultSize
props directly onButton
packages/components/src/border-control/border-control/component.tsx
Outdated
Show resolved
Hide resolved
packages/components/src/border-control/border-control/component.tsx
Outdated
Show resolved
Hide resolved
packages/components/src/border-box-control/border-box-control/component.tsx
Outdated
Show resolved
Hide resolved
/> | ||
) } | ||
<BorderBoxControlLinkedButton | ||
onClick={ toggleLinked } | ||
isLinked={ isLinked } | ||
size={ size } | ||
size={ inputHeight } |
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.
Nit: we can rewrite the linked button styles in a way that doesn't need the size
prop at all. I also realized that the linked button uses the isSmall
deprecated prop, which should be replaced by size="small"
Something like this:
diff --git a/packages/components/src/border-box-control/border-box-control-linked-button/component.tsx b/packages/components/src/border-box-control/border-box-control-linked-button/component.tsx
index ee76c39742..5388a381de 100644
--- a/packages/components/src/border-box-control/border-box-control-linked-button/component.tsx
+++ b/packages/components/src/border-box-control/border-box-control-linked-button/component.tsx
@@ -29,7 +29,7 @@ const BorderBoxControlLinkedButton = (
<View className={ className }>
<Button
{ ...buttonProps }
- isSmall
+ size="small"
icon={ isLinked ? link : linkOff }
iconSize={ 24 }
aria-label={ label }
diff --git a/packages/components/src/border-box-control/border-box-control-linked-button/hook.ts b/packages/components/src/border-box-control/border-box-control-linked-button/hook.ts
index 3d535a6583..1d00d059ad 100644
--- a/packages/components/src/border-box-control/border-box-control-linked-button/hook.ts
+++ b/packages/components/src/border-box-control/border-box-control-linked-button/hook.ts
@@ -16,17 +16,16 @@ import type { LinkedButtonProps } from '../types';
export function useBorderBoxControlLinkedButton(
props: WordPressComponentProps< LinkedButtonProps, 'button' >
) {
- const {
- className,
- size = 'default',
- ...otherProps
- } = useContextSystem( props, 'BorderBoxControlLinkedButton' );
+ const { className, ...otherProps } = useContextSystem(
+ props,
+ 'BorderBoxControlLinkedButton'
+ );
// Generate class names.
const cx = useCx();
const classes = useMemo( () => {
- return cx( styles.borderBoxControlLinkedButton( size ), className );
- }, [ className, cx, size ] );
+ return cx( styles.borderBoxControlLinkedButton(), className );
+ }, [ className, cx ] );
return { ...otherProps, className: classes };
}
diff --git a/packages/components/src/border-box-control/border-box-control/component.tsx b/packages/components/src/border-box-control/border-box-control/component.tsx
index dbef63eeb5..576a4ebd27 100644
--- a/packages/components/src/border-box-control/border-box-control/component.tsx
+++ b/packages/components/src/border-box-control/border-box-control/component.tsx
@@ -143,7 +143,6 @@ const UnconnectedBorderBoxControl = (
<BorderBoxControlLinkedButton
onClick={ toggleLinked }
isLinked={ isLinked }
- size={ inputHeight }
/>
</View>
</View>
diff --git a/packages/components/src/border-box-control/styles.ts b/packages/components/src/border-box-control/styles.ts
index 3fba981080..6007f9671a 100644
--- a/packages/components/src/border-box-control/styles.ts
+++ b/packages/components/src/border-box-control/styles.ts
@@ -22,12 +22,11 @@ export const wrapper = css`
position: relative;
`;
-export const borderBoxControlLinkedButton = (
- size?: 'default' | '__unstable-large'
-) => {
+export const borderBoxControlLinkedButton = () => {
return css`
position: absolute;
- top: ${ size === '__unstable-large' ? '8px' : '3px' };
+ top: 50%;
+ transform: translateY( -50% );
${ rtl( { right: 0 } )() }
line-height: 0;
`;
diff --git a/packages/components/src/border-box-control/types.ts b/packages/components/src/border-box-control/types.ts
index 283faf0501..a08cae1661 100644
--- a/packages/components/src/border-box-control/types.ts
+++ b/packages/components/src/border-box-control/types.ts
@@ -53,7 +53,7 @@ export type BorderBoxControlProps = ColorProps &
__next40pxDefaultSize?: boolean;
};
-export type LinkedButtonProps = Pick< BorderBoxControlProps, 'size' > & {
+export type LinkedButtonProps = {
/**
* This prop allows the `LinkedButton` to reflect whether the parent
* `BorderBoxControl` is currently displaying "linked" or "unlinked"
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.
packages/components/src/box-control/styles/box-control-styles.ts
Outdated
Show resolved
Hide resolved
const RootWidth = ( { | ||
__next40pxDefaultSize, | ||
}: Pick< BoxUnitControlProps, '__next40pxDefaultSize' > ) => { | ||
const maxWidth = __next40pxDefaultSize ? '320px' : '235px'; |
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.
@jameskoster I believe that @brookewp was requesting feedback in particular regarding this change:
I've included some changes to the width when the prop is enabled, otherwise, the text isn't visible.
Personally, I believe there's a chance that this new width may not really come into effect when the component is used in the editor's sidebar: (this can also be tested in storybook itself)
If that's the case, we may have to think about alternative solutions to make sure that all inputs can show the text, while also fitting in the sidebar
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.
Possibly a silly question... I understand why a min-width is required on the inputs, but why do we need a max-width? Can't they just scale?
I guess that's separate...
Inspector aside, shouldn't the component be able to scale down to smaller sizes regardless? 280px (Inspector width) is small, but not that small...
All that said, I don't know if this one component is worth prioritising – I'm not sure it's even used in core.
Apologies if I'm still misunderstanding the question.
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.
why do we need a max-width? Can't they just scale?
That's a good point. I agree that components should rarely have a max-width (it should be the consumer of this component to add one, if needed). @brookewp , could you look into that, and in particular if (by looking at the history of the component) there's a clear reason for having the max-width
?
Inspector aside, shouldn't the component be able to scale down to smaller sizes regardless? 280px (Inspector width) is small, but not that small...
Apologies if I'm still misunderstanding the question.
Regardless of whether we should be setting a max-width in the component or not, if I understand correctly @brookewp is flagging that, when rendering the UnitControl
components with the new 40px
height, those inputs need to be wider in order to show their values.
And potentially, when using this component in the editor sidebar, the available width (280px - 2*16px padding) = 248px) may not be enough to have four UnitControls in their "40px" configuration, without cutting the text inside those inputs.
All that said, I don't know if this one component is worth prioritising – I'm not sure it's even used in core.
I think that BoxControl is still used in the dimensions panel (see message below).
It would be great if we could get a list sorted by priority — although ultimately I seem to remember that all components need to be refactored to the new 40px size. We'd like to wrap up the migration sooner rather than later, so that we can refactor our UIs and ultimately remove both the __next40pxDefaultSize
prop and the __unstable-large
size.
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.
Gotcha. I think the point stands though – since BoxControl is not restricted to the Inspector, it should scale elegantly to smaller widths? If we wanted to reuse existing patterns, here some options:
Custom padding (when spacing presets are provided)
(The settings button would be omitted).
Border control
(The color picker would be omitted).
I don't have a strong feeling either way. As I said this component isn't used in core very often since most themes provide spacing presets nowadays. If neither of these patterns will work, or are too difficult to implement, then we'll probably need to revisit the design.
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.
(this can also be tested in storybook itself)
Such a helpful TIL 🥲 Thank you!
could you look into that, and in particular if (by looking at the history of the component) there's a clear reason for having the max-width ?
This was part of the initial creation of the component three years ago. Nothing was mentioned in relation to the width/input size. The component was made for the Cover block, so my guess is it was sized to fit within the sidebar. So I don't think a hard width is needed.
And potentially, when using this component in the editor sidebar, the available width (280px - 2*16px padding) = 248px) may not be enough to have four UnitControls in their "40px" configuration, without cutting the text inside those inputs.
Looks like that's the case; it's not wide enough 😓
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.
As I said this component isn't used in core very often since most themes provide spacing presets nowadays.
So it is likely there for backwards compability? Since it shows in the case when showSpacingPresetsControl
is false
. And it was added quite recently in #48070.
since BoxControl is not restricted to the Inspector, it should scale elegantly to smaller widths? If we wanted to reuse existing patterns, here some options:
@ciampo should we look into an alternative pattern when __next40pxDefaultSize
is enabled?
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.
So it is likely there for backwards compability?
Yes. So rather than coming up with a new design it would be simpler to re-use existing patterns (like the padding / border examples above). That way the component will work nicely in any environment, not just the Inspector. What do you think?
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 believe the Custom padding
option makes the most sense for BoxControl
. However, are we okay with imposing a limitation on the values by includingRangeControl
? cc @ciampo
If not, are we okay with the Border control
option when there are only two values? cc @jameskoster
For example:
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 agree with Brooke, the layout of the custom padding controls feels like a better fit — although that means that we'll have to introduce a slider next to each input.
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.
That works for me.
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.
On a separate note, I realsed that BoxControl
's storybook file hasn't been updated to the same format that other components use (ie. with a meta
object, and using the template + args
format). Which means that currently, controls are not enabled for its storybook examples. Would you be able to improve this too? (it can definitely happen in a separate PR)
I believe the component is behaving as expected, since the top border in your screenshot has a width of
It looks like it is used in the dimension panel for padding/margin/block gaps, when spacing presets (which I don't know what they are) are not used |
Derp, of course 🤦♂️ |
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 putting all of this together @brookewp!
I saw and agree with Marco's comment on the benefit of using __unstable-large
. One thing related to that that stood out to me is that on this PR there are some style changes on the unit selector that appear to come from __unstable-large
, in addition to the size itself. So that will need to be preserved when __unstable-large
and __next40pxDefaultSize
are both eventually deprecated.
So, to recap, it looks like there are a few pre-requisites and/or follow-ups to this PR. Here's a suggested plan of action:
What do folks think? |
A status update on the prelude to this PR via the plan ciampo shared above (steps 1-2):
|
a23876d
to
11a22e2
Compare
Code changes are nice and clear, and overall things are looking good. One thing that I was wondering, is whether we should also forward the new 40px default size to the components in the dropdown of That could also happen in a follow-up, but it would mean updating a few more components to support the new sizing scheme. (cc @jameskoster ) |
Potentially, yes! Though I would rather prioritise updating the swatch buttons to use the 32/40 sizing convention. |
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 believe we can merge this PR (after rebasing, which should also fix the CI failures) 🚀
We could then follow-up on updating the componentry in BorderControl
's dropdown:
Potentially, yes! Though I would rather prioritise updating the swatch buttons to use the 32/40 sizing convention.
@mirka 's work in #57562 is already potentially taking care of the "style" section in the dropdown.
@brookewp , maybe you could take a look at the swatch buttons? I guess we could:
- add a
size
prop which adds asize="compact"
(32px) - add the usual opt-in prop for chaing the default size to 40px
What do y'all think?
@jameskoster Just to be clear, are there actual use cases where the CircularOptionPicker needs to be 32 in some places but 40px in others? In most (all?) consumer components (ColorPalette, DuotonePicker, GradientPicker, PaletteEdit), I'm hoping we can just update the swatch button sizes internally to a single new size without providing multiple size options. |
11a22e2
to
c8e7f47
Compare
It's hard to say without doing a full audit, but I'd be inclined to say they should always all be the same size. It certainly seems fine to start with a single size. |
Part of #46741
What?
Add a new opt-in prop
__next40pxDefaultSize
toBoxControl
,BorderControl
, andBorderBoxControl
, following the plan outlined in above mentioned PR.Why?
For more consistency in styling. I've grouped these three together since they are very similar.
How?
A new, temporary
__next40pxDefaultSize
prop. When the prop is set totrue
, the input will have a height of 40px.BoxControl
I've included some changes to the width when the prop is enabled, otherwise, the text isn't visible. I used the sizing from
BorderControl
's compact size, but I'd like to hear from @WordPress/gutenberg-design on this.Also, due to the narrow size, only 2-3 numbers will be visible without a horizontal scroll.
Testing Instructions
In Storybook:
npm run storybook:dev
In the editor
Smoke test the components in the editor;
BoxControl
,BorderControl
, andBorderBoxControl
shouldn't have any visible changes for now.Note
BoxControl
is only used inDimensionsPanel
for backward compatibility. The only way I've been able to test it is by settingshowSpacingPresetsControl
to true here:gutenberg/packages/block-editor/src/components/global-styles/dimensions-panel.js
Lines 487 to 499 in d69ee81
However,
__next40pxDefaultSize
causes issues inBoxControl
, where the text in the input is not visible due to the width constraints of the inspector. So we may need to pause this forBoxControl
to reassess the design.