InputControl-based components: Add opt-in prop for next 40px default size #53819
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mirka
added
[Type] Enhancement
mirka
changed the title
|
Size Change: +69 B (0%) Total Size: 1.62 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 339dbc1. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5907808106
|
mirka
force-pushed
the
input-control-40px
branch
from
0b96c24
to
bc60e00
Compare
mirka
commented
Sep 6, 2023
ciampo
reviewed
Sep 12, 2023
There was a problem hiding this comment.
Thank you @mirka for working on this!
- ✅ Code changes look good
- ✅ Components on Storybook look and behave as expected (with new 40px height)
- ✅ Deprecated logic around 36px prop works as expected
- ⏳ Gave a quick look at the editor, but I could do with a few extra pairs of eyes
@WordPress/gutenberg-design @brookewp @chad1008 could you give this and check that input-based controls are looking good? (see PR description for a detailed list of what to look for).
Also, note that not all components are upsized yet — as Lena mentioned in the PR description:
Similar placeholder components in other core blocks are not upsized yet — this should be done separately.
[...]
The other components in the Advanced section are not upsized yet — this should be done separately.
One this PR is completed, we can follow up and upsize the remaining input components via the __next40pxDefaultSize prop.
|
I didn't see any issues in the Editor. Excited to get everything sized consistently, I'm currently seeing inputs that are 30, 36, 40px, sometimes in the same block inspector 🙈 |
I know, right? Once this PR lands, feel free to start using the |
|
The next step is to ensure the same default font size and left/right padding for the compact (32px tall) button, so it becomes a just less tall version of the default 40px button. |
brookewp
reviewed
Sep 18, 2023
ciampo
approved these changes
Sep 29, 2023
There was a problem hiding this comment.
LGTM 🚀
The next step is to start applying the __next40PxDefaultSize prop around the editor and make any necessary tweaks in the process.
@jameskoster , could you give us guidance on where we should start applying this prop in the editor? Or should we do it literally on every instance of these controls?
Feel free to also go ahead and apply this prop yourself — I guess you and @chad1008 can coordinate the effort together :)
The next step is to ensure the same default font size and left/right padding for the compact (32px tall) button, so it becomes a just less tall version of the default 40px button.
Hey @jasmussen , just wanted to make sure if this point is still relevant given the current implementation of Button — if so, could you be more specific on what exactly needs to be done? Thank you!
|
From my POV, the plan remains #46734, which is only have two sizes, 40px (default) and 32px (small or compact), same font size, just different height. CC: @richtabor @SaxonF |
chad1008
force-pushed
the
input-control-40px
branch
from
8af8b86
to
6f6b4ac
Compare
We've recently made changes to support a default 40px size (via the @chad1008 , could you add to the list of follow-ups making sure that both the compact and default size of |
Confirmed. |
|
Cool! Then this can happen: #55079 |
|
Very nice! Can I ask for TextControl next? That'll get us in a decent spot consistency wise. 😅 |
|
Yup, with @chad1008 we recently discussed working on |
ciampo
added
the
has dev note
|
For the dev note, see #46741 |
12 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of #46741
What?
For all the InputControl-based components listed below:
__next40pxDefaultSizeprop to opt into the next 40px default size.__next36pxDefaultSizeas deprecated, and alias to the 40px prop.InputControl-based components
Silently upsized components
The following usages were upsized/tweaked to reflect the size change from 36px to 40px.
DateTimePicker / TimePicker
Block editor ▸ Position control (Add a Row block and find the Position control in the block inspector)
Block library ▸ RSS block
Similar placeholder components in other core blocks are not upsized yet — this should be done separately.
Block library ▸ Template Part ▸ Advanced ▸ Import controls (Open a template in the Site Editor, add a new template part, and see the Advanced section in the block inspector)
Testable with diff
The other components in the Advanced section are not upsized yet — this should be done separately.
Why?
We need to supersede the outdated
__next36pxDefaultSizeprops and transition to the new 40px default sizes.Apologies for the relatively large surface area of this PR, since this needs to be done in one go.
How?
See code comments for noteworthy details.
Testing Instructions
npm run storybook:dev__next36pxDefaultSizehas a defined value, there should be a deprecation warning in the console. When it's truthy, it should work the same as__next40pxDefaultSize(i.e. should have 40px height and not 36px).__next40pxDefaultSizeis falsey, it should have no effect on the existing size variations. When it's truthy, it should make thedefaultsize variant be equivalent to the__unstable-largevariant.