Update buttons and icons buttons size and consistency

[youknowriad]

I've noticed that our current Button components have inconsistent sizes (between IconButton and regular Button), So I was working on consolidating the APIs and making sure everything is consistent.

While doing so we have to make some decisions about the size of the default buttons, small and large.
So I went with 36px for the default size (currently the default for the IconButton), 24px for the small size (like today).

I decided to remove the large size because it doesn't make sense when the default button size is 36px.

Once this PR lands, we should follow-up with a Core ticket for consistency across all WP-Admin.

I also added a story to show all the different variations in one single place.

Breaking changes

There's a few style breaking changes, I don't think these will have big impacts on third party usage though.

• The main breaking change is that there's a defined height in the "Button" component. If you're using the "Button" component and expecting its height to grow with the content, you should override the height with height: auto.
• Another change here is that small or large buttons don't receive the "default" style variations by default, it should be explicit.

Testing instructions

• Check all the buttons in Gutenberg :)

[youknowriad]

Right now we expect icon buttons across Gutenberg UI to have the dark borders on hover while the default buttons (without any variations) don't have this UI. This forces us to have these overrides here.

Ideally, we don't need this and the IconButton should only have to deal with icons, everything else should be deferred to the regular Button component and style.

cc @jasmussen

[youknowriad]

This is fixed in the last commit 5d35623 but it means that if use a Button without specifying a variation and we expect a custom hover styles, we'd have to override the default, !important is the simplest way to achieve that.

[gziolo]

Awesome work, you are my hero. I had a really hard time trying to unify some of the styles related to buttons 😅

[karmatosed]

I will let others comment to, but this all feels like a great opportunity to go larger not smaller. I think almost keeping the larger size over smaller could be ace. Bringing in with this the newer UI feels like a great step.

[jasmussen]

Impressive work simplifying things here. This is the most visible change as the publish/preview buttons are now 2px taller:

Paired with other spacing efforts, this is good, as it moves the default button closer to the grid system.

The icon buttons should remain square, though, regardless of size, with the vertical ellipsis currently being the only intentional exception to that rule:

[youknowriad]

Since the IconButton should remain square (if no text used) and the icon size is 20px this means the padding should be 8px on each size and not 10 and ideally consistent on all buttons including icon buttons.

[youknowriad]

I think almost keeping the larger size over smaller could be ace.

@karmatosed I'm removing the isLarge variation because the default is larger.

[gziolo]

I was about to report the issues with misplaced icons in the icon button but you were faster with 994654f. 🎉

I couldn't find any regressions in comparison with recent refactorings. Awesome work. There is still one issue with spacing in the toolbar for buttons, but it exists in master so it should be tackled separately:

I noticed also a slight change in the hover state for menu items. It brings consistency so I don't think it's concerning. However, it should be approved by designers.

this branch

master

[jasmussen]

Since the IconButton should remain square (if no text used) and the icon size is 20px this means the padding should be 8px on each size and not 10 and ideally consistent on all buttons including icon buttons.

I think that's perhaps a simplistic take. I agree in code purity principle, but due to how browsers render text, we often have to massage the paddings and make exceptions. There are some gnarly details in https://youtu.be/jnV1u67_yVg?t=642

This is what I see now:

The padding left and right for normal buttons here does seem a little tight, honestly I think it could be much more relaxed, but I acknowledge your iconbutton point. It's probably worth moving forward with what we have here as it's not terrible, and we need to acknowledge that Mobile is a factor in making the buttons wider.

But perhaps in a followup PR, I would love to tweak the horizontal padding further for buttons to make it more harmonious. This horizontal padding additionally serves the purpose of ambiguating from an input field, which is especially important given the more minimalist style of buttons currently.

[gziolo]

I think those text buttons in the toolbar look a bit different but it still feels okay.

HTML focused, Preview hovered and pressed

HTML hovered, Preview pressed

[gziolo]

Not that I care that much, but something to consider.
Shouldn't be IconButton documented under its own component?

For reference, this is how sizes are presented for the Icon component.

https://wordpress.github.io/gutenberg/?path=/story/components-icon--sizes

@ItsJonQ, it's something we should standardize and wrap with some helper component so we don't have to repeat those wrappers and styles over and over again. Ideally, we could code it along those lines:

<Variations label="Small Buttons">
	<Button isSmall>Button</Button>
	<Button isPrimary isSmall>Primary Button</Button>
	<Button isDefault isSmall>Secondary Button</Button>
	// ...
</Variations>

[youknowriad]

to be honest, I think we can remove the IconButton component entirely in favor of an icon prop in the Button component (that's separate from this PR though).

the main reason I used a single story is to be able to visualize all variations in the same screen.

[gziolo]

to be honest, I think we can remove the IconButton component entirely in favor of an icon prop in the Button component (that's separate from this PR though).

There is an issue for that for sure. I like the idea :)
You should merge this PR as soon as it's confirmed by someone from the design team :)

[ItsJonQ]

@ItsJonQ, it's something we should standardize and wrap with some helper component so we don't have to repeat those wrappers and styles over and over again.

@gziolo I think that's a great idea :). I started doing that for the G2 Prototypes I've been making

https://tz3ir.csb.app/#/buttons

[gziolo]

You are always ahead of time @ItsJonQ, this is exactly what I had in mind :)

[youknowriad]

thanks all for the feedback, it looks like we're all in favor of this change. I'm well aware that this might introduce small issues here and there but I'm choosing to merge it soon in order to find these as soon as possiible.

[jasmussen]

Sorry for not catching this, but this PR appears to have caused a small issue with the button colors.

Before:

The gray color is #555d66 (which is $dark-gray-500).

After:

The color here is unset and defaults to what the browser provides, which is a semi-opaque black that translates to #222222 on a white background.

The last HEAD that worked was the one before this one in the commitlist, b2ef0f550b5e0fc549742f3dfbef2bea89155169.

[jasmussen]

Removing this is possibly what caused the regression. If the color shouldn't live here, then it needs to live elsewhere so the button can inherit it, for example using currentColor.

[youknowriad]

My main issue is that the color shouldn't be different between Button and IconButton so we should move this to the Button stylesheet.

[youknowriad]

Fix here #19123

[afercia]

I'm thinking of an 8px grid system with options for 4 and 12px usage. With icons being 24px and a block toolbar being 48px, 36px is compatible (9x4). Right now there's 28px some places, and 34px in others, so it's a bit messy. 12/24/36/48 is technically base12 but is 8px grid compatible it feels like.

I don't think it's necessarily something that has to happen with this PR, other than the capacity in which it already is (small = 24px, large = 36px). I think Dave Whitley had created a grid scale that might be a good next step?

Worth noting in the proposal from @davewhitley there's no 36px size. The proposed spacing system is as follows:

Grid Unit 0.5    4px
Grid Unit 1      8px
Grid Unit 1.5    12px
Grid Unit 2      16px
Grid Unit 3      24px
Grid Unit 4      32px
Grid Unit 5      40px
Grid Unit 6      48px

See https://make.wordpress.org/design/2019/10/31/proposal-a-consistent-spacing-system-for-wordpress/

Once this PR lands, we should follow-up with a Core ticket for consistency across all WP-Admin.

Worth also noting that buttons in the WordPress admin do have a large size, which is currently 32px on large screens and 40px on small screens. Sizes used in core can certainly be changed but I'd tend to think a larger discussion should have happened before introducing these changes in Gutenberg.

Changes that affect WordPress as a whole should be discussed by various team and not forced in core just because of a change in Gutenberg.

Worth also considering that in core many forms have buttons aligned horizontally with other form elements like input fields and selects. Increasing the height of the buttons would require to increase the other form elements height as well. It's going to be a large change that I'm not fully sure it can be done so lightly.

Examples of such alignments are everywhere in the admin, for example in the Posts screen:

Regarding the fixed heights:

In WordPress 5.3 there has been a lot of work to remove all form elements and buttons fixed heights. This is to allow these elements to scale with text zoom and not cut-off their content. Worth also noting this requirement came from the WPCampus Gutenberg accessibility report, that should be familiar to the Gutenberg team.

Reference:
#15356
https://core.trac.wordpress.org/ticket/47477
https://core.trac.wordpress.org/changeset/46243

I just proposed to discuss these points in the next Accessibility team meeting tomorrow (Friday, February 20) on the WordPress Slack in the #accessibility channel. Everybody's welcome to join.

[aduth]

Regarding the fixed heights:

It doesn't seem like it should strictly be necessary here either. Even if there was a desired default height (36px), I assume it would still be possible to achieve this with some combination of borders, padding, and margins. I expect this would still achieve the same effect without being so rigid, and being more tolerant to how text sizes can scale.

In the implementation, I can see how it might have been made more challenging because the target size is assigned as a variable.

gutenberg/packages/base-styles/_variables.scss

Line 81 in c84784f

$icon-button-size: 36px;

But I think even with the variable, we could use some arithmetic to work back to padding (accounting for font size, line height, borders, etc).

Partially implemented pseudo-code:

diff --git a/packages/components/src/button/style.scss b/packages/components/src/button/style.scss
index 7ca65b027..a10a90f16 100644
--- a/packages/components/src/button/style.scss
+++ b/packages/components/src/button/style.scss
@@ -9,10 +9,9 @@
 	background: none;
 	transition: box-shadow 0.1s linear;
 	@include reduce-motion("transition");
-	height: $icon-button-size;
 	align-items: center;
 	box-sizing: border-box;
-	padding: 0 8px;
+	padding: round( ( $icon-button-size - ( $default-font-size * $default-line-height ) ) / 2 ) 8px;
 	overflow: hidden;
 	border-radius: 3px;
 	color: $dark-gray-500;

(Would need further changes for buttons with borders, small buttons, etc)

[afercia]

Yes there are a few ways.

The current implementation in core is based on min-height and line-height. It removed any top and bottom padding.

That's also what has been recommended to plugin authors in the dev note post published on Make, see https://make.wordpress.org/core/2019/10/18/noteworthy-admin-css-changes-in-wordpress-5-3/

In general, plugin authors and WordPress developers are encouraged to:

• remove any fixed heights: flexible heights are the WordPress recommended standard (and one of the main goals of the Admin CSS changes).
• remove any custom top and bottom padding values.
• remove any custom line-height values.
• update their CSS code to override new focus/hover buttons colors if they use custom colors on this type of element.

[davewhitley]

Yep, I haven't worked on it in a while, but in my latest designs (a few months ago) I used 32px for the compact button size and 40px for the regular button size. Or 32px for the regular and 40px for the large size; however you want to look at it.

I decided not to go below 32px because I felt 24px was unnecessarily small. I found that the small button sizes were rarely used in WordPress from what I could tell. 32px/40px also played nicely with other elements like form fields and selects when a consistent height is desired. Those sizes also scale well to mobile, and I found that having different sizes on a mobile device was not necessary.

[aduth]

At least concerning the fixed heights, as noted with the given precedent, the most direct option may be to turn heights to min-height in the adjusted styles?

gutenberg/packages/components/src/button/style.scss

Line 12 in 0609348

height: $icon-button-size;

gutenberg/packages/components/src/button/style.scss

Line 194 in 0609348

height: 24px;

It seems to achieve the same desired effect, without limiting growth.

If it can work, this note from the devnotes post would need to be removed or adapted

Also, for consistency between the design of all the button variations, the buttons now have an explicit height in their CSS style. If you were relying on the fact that the height of buttons is dynamic and should adapt to its content, make sure to override the style of your button and add the following CSS rule.

It becomes more the inverse now; if plugin developers were assigning an explicit height, they'd need to set min-height: auto as well.

For what it's worth, looking at the changes, I don't know that this pull request introduces the fixed heights, as I see they were there previously, at least for any of the "prestyled" buttons.

Example: https://github.com/WordPress/gutenberg/pull/19058/files#diff-169503e5275f964f8bd036a7bfcd8f7cL14-L16

Example: https://github.com/WordPress/gutenberg/pull/19058/files#diff-169503e5275f964f8bd036a7bfcd8f7cL194-L198

I'd still think using padding and avoiding specific height values would be preferable as a general solution to these sorts of requirements, but it's a bigger discussion than we probably want to address for short-term solution.

[mapk]

For what it's worth, looking at the changes, I don't know that this pull request introduces the fixed heights, as I see they were there previously, at least for any of the "prestyled" buttons.

Great detective work there, @aduth.

I'd still think using padding and avoiding specific height values would be preferable as a general solution to these sorts of requirements, but it's a bigger discussion than we probably want to address for short-term solution.

Looks like maybe the next step is to get a PR open for discussion and testing?

[mapk]

Looks like zoom testing has been done. So addressing my comment above and closing any loops: #15359 (comment)

[nicolad]

hey @youknowriad
currently, I am trying to make some progress on: #15830
this overflow: hidden; is causing some issues:
before

---

after

[nicolad]

can you please help me understand what issue was fixing this overflow: hidden;?
or maybe you have a solution for those cut labels?

[youknowriad]

I'm not really certain it's needed. I believe this PR just copied it from the icon button stylesheet.

[StevenDufresne]

This is also causing an issue with a block directory button. @nicolad Did you reach any solution on this?

[paaljoachim]

I just want to mention this PR:
Update: Post publish buttons and alignment.
#22390

As the post publish buttons is getting an update. We are removing the X seen next to the Publish button on pre-publish mode, and instead aligning a close button next to the publish button.