Make WordPress Core

Opened 5 months ago

Last modified 4 months 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.9 Priority: normal
Severity: normal Version:
Component: Administration Keywords: needs-design-feedback has-patch early
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 5 months ago.
SCR-20250125-kkqa.png (329.9 KB) - added by karmatosed 5 months ago.
SCR-20250125-ktgu.png (140.2 KB) - added by karmatosed 5 months ago.
SCR-20250125-ktiq.png (199.3 KB) - added by karmatosed 5 months ago.
SCR-20250125-ktkv.png (199.2 KB) - added by karmatosed 5 months ago.
SCR-20250125-kxxf.png (260.6 KB) - added by karmatosed 5 months ago.
tenon-screenshot.png (278.6 KB) - added by afercia 5 months ago.
Less than ideal enlarged text for inputs and buttons pre-WordPress 5.3

Download all attachments as: .zip

Change History (22)

#1 @karmatosed
5 months ago

  • Focuses ui css added

#2 @karmatosed
5 months ago

  • Component changed from General to Administration

#3 @karmatosed
5 months ago

  • Type changed from defect (bug) to enhancement

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


5 months ago

#5 @afercia
5 months 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
5 months 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
5 months 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
5 months 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.


5 months ago

#9 @fabiankaegy
4 months ago

#62933 was marked as a duplicate.

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


4 months ago
#10

  • Keywords has-patch added; needs-patch removed

#11 @fabiankaegy
4 months 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 months 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

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


4 months ago

#14 @joedolson
4 months ago

  • Keywords early added
  • Milestone changed from 6.8 to 6.9

Given the complexity of this in terms of edge cases and extender adaptations, we're moving it to the 6.9 milestone to give it more time. It's still a priority to get done relatively quickly, but it definitely needs to be in core early in the cycle.

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


4 months ago

Note: See TracTickets for help on using tickets.