Make WordPress Core

Opened 2 weeks ago

Last modified 4 hours ago

#62864 assigned enhancement

Add padding and color changes to buttons and inputs

Reported by: karmatosed's profile karmatosed Owned by: fabiankaegy's profile fabiankaegy
Milestone: 6.8 Priority: normal
Severity: normal Version:
Component: Administration Keywords: needs-design-feedback has-patch
Focuses: ui, accessibility, css Cc:

Description

This continues the work from ticket that brought in the light background: https://core.trac.wordpress.org/ticket/62831. This one is a bit different though and has more changes, so I have screenshots and can prepare a patch depending on appetite.

In Storybook and the site editor the following values could be brought in:

  • Inputs to have padding: 6px 12px and height 40px where have space, for example settings.
  • No background color on secondary buttons.
  • Primary buttons to have a height of 40px, where have space, for example not in line with another input or in headings.
  • Compact option of 32px height: for toolbars and headers: this is used in site editor header so we can translate to use it for post/pages. For compact, I also had to adjust the line-height down for all types of input when doing this work.

Links in Storybook are:

https://wordpress.github.io/gutenberg/?path=/story/components-textcontrol--with-label-and-help-text&globals=css:wordpress
https://wordpress.github.io/gutenberg/?path=/story/components-button--primary&globals=css:wordpress

Attached are images how this looks in site editor and also how this then could look on some key screens in the admin screen. I used 40px for the admin screen and 32px for headers.

There are however some issues with this would need to be addressed:

  • Heights of sections would need to be adjusted, for example headers of post/pages button rows. (Done in mocks to show).
  • Spacing on headers for post/pages needs to have margin added with heading and 'new' buttons. (Done in mocks to show).
  • Line-height work needs doing for lists on settings page (that hasn't been done in mocks).

This is a bigger change so deserves its own ticket. It is however maybe a really good one to consider because it makes everything seem a bit more belonging. That said if this is too far what could happen is:

  • Just remove background color from the secondary button.
  • Consider using the compact option for all at 32px height. It is an increase at least.

Unfortunately just adding height to inputs doesn't work without also doing it to buttons as that impacts lines where both are.

I am curious if this helps accessibility as it does come from the site editor itself into admin but if also improves that it would be a win. It this doesn't I don't want to suggest anything impacts, so adding that focus for input.

Attachments (7)

SCR-20250125-kknw.png (411.7 KB) - added by karmatosed 2 weeks ago.
SCR-20250125-kkqa.png (329.9 KB) - added by karmatosed 2 weeks ago.
SCR-20250125-ktgu.png (140.2 KB) - added by karmatosed 2 weeks ago.
SCR-20250125-ktiq.png (199.3 KB) - added by karmatosed 2 weeks ago.
SCR-20250125-ktkv.png (199.2 KB) - added by karmatosed 2 weeks ago.
SCR-20250125-kxxf.png (260.6 KB) - added by karmatosed 2 weeks ago.
tenon-screenshot.png (278.6 KB) - added by afercia 12 days ago.
Less than ideal enlarged text for inputs and buttons pre-WordPress 5.3

Download all attachments as: .zip

Change History (19)

#1 @karmatosed
2 weeks ago

  • Focuses ui css added

#2 @karmatosed
2 weeks ago

  • Component changed from General to Administration

#3 @karmatosed
2 weeks ago

  • Type changed from defect (bug) to enhancement

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


13 days ago

#5 @afercia
13 days ago

Not opposed to increase the spacing for inputs and buttons. From a technical side, it is important to consider that at the moment inputs don't use vertical padding for a reason. They use line-height to allow the inputs to not cut-off text when the font size is increased via the operating system (default size or text-only zoom for example).
This implementation was part of a major refactoring of all the inputs and should be preserved.

#6 @audrasjb
13 days ago

I agree with Andrea's above comment. This patch is going to be technically a lot more difficult to handle than the other related tickets, since touching line heights and paddings/margins will affect a lot of use cases in WP Admin.
Anyone is welcome to work on a first draft PR by the way :)

#7 @afercia
12 days ago

For some history and context: WordPress 5.3 brought in some relevant changes for form controls, buttons and the like that are very well summarized in the dev note that was published at that time by @audrasjb at https://make.wordpress.org/core/2019/10/18/noteworthy-admin-css-changes-in-wordpress-5-3/. Quoting from the dev note:

remove any fixed heights: flexible heights are the WordPress recommended standard (and one of the main goals of the Admin CSS changes)

In fact, one of the most relevant changes for inputs and buttons was to remove any fixed height to allow text enlarged via the operating system user preferences or by other means to not be cut-off.

Fixed heights should be avoided to allow text to still be fully visible. Previously, enlarged text was very problematic as illustrated in the attached screenshot pre-5.3.

Also, vertical (top and bottom) padding should be avoided because, especially for inputs, it may partially cut-off text. That's the reason why in core the heights are determined via a unitless line-height value. This way, the inputs and buttons height scales together with the enlarged text. This mechanism should be preserved.

Unfortunately, the block editor inputs and buttons use a fixed height. That's less than ideal and inconsistent with what Core does. Ideally, fixed heights should be removed from the block editor implementation.

ReferencesL
https://core.trac.wordpress.org/ticket/47477
https://core.trac.wordpress.org/ticket/48420

@afercia
12 days ago

Less than ideal enlarged text for inputs and buttons pre-WordPress 5.3

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


6 days ago

#9 @fabiankaegy
4 hours ago

#62933 was marked as a duplicate.

This ticket was mentioned in PR #8283 on WordPress/wordpress-develop by @fabiankaegy.


4 hours ago
#10

  • Keywords has-patch added; needs-patch removed

#11 @fabiankaegy
4 hours ago

I attached my patch to the issue to let you know I'm working on it. But after seeing the discussion here I will have to revisit how the padding / line height is handled.

#12 @fabiankaegy
4 hours ago

  • Owner set to fabiankaegy
  • Status changed from new to assigned

I have updated my patch accordingly. The height of the various elements is now again only handled via the min-height & line-height properties

Note: See TracTickets for help on using tickets.