Admin CSS: standardize form controls heights, alignments, etc.

[afercia]

The core default styles don't set a standardized height for form controls. Only buttons have 4 default sizes. Inputs and selects don't.

This is very noticeable when aligning form controls horizontally. Here's an example from WordPress 5.2 (Chrome and Firefox):

See how select, input=text, input=number, and buttons have different default heights and the alignment is far from ideal.

To make form controls align nicely when necessary, for example at the top of the Posts list, core sets a series of exceptions to the default styling, overriding the default CSS.

Wouldn't be nice to have standard heights and nice alignments by default instead? Here's an example with the new styles introduced in WordPress 5.3:

Not to mention plugins that align form controls horizontally are forced to override the core CSS.

This shouldn't happen: core should provide good default styling and not ask plugin authors for extra work.

During a recent ​design and accessibility teams shared meeting on Slack (requires registration) it was agreed to standardize the height of all form controls to 30 pixels so this is a follow up to ​the admin CSS changes introduced in WordPress 5.3 see ticket:47477#comment:67

Main goal of this proposal:

• make form controls have the same default height of 30 pixels and align nicely
• this way, various exceptions are no longer necessary
• the small, normal, large and hero button heights would change from the WordPress 5.2 heights of 24 / 28 / 30 / 46 pixels to 26 / 30 / 32 / 46 so that the normal size is 30 pixels and the ratio between sizes is preserved
• improve the new form controls styling in some areas, for example in the Customizer

Mobile:

On WordPress 5.2 and previous versions:

• all the button sizes except "hero" are "flattened" to a height of 31 pixels
• input=text, input=number, input=email and input=password fields get a height of 40 pixels
• selects get a height of 40 pixels
• input=search fields and other rarely used inputs (date, time, etc.) get a height of 32 pixels
• input=url fields get a height of 26 pixels
• the Customiser overrides and resets the core responsive styles: in my opinion this isn't a good idea and should be reviewed
• ideally, there should be no exceptions in core: all the form controls should always have the default styling

On WordPress 5.3:
Some of these inconsistencies are already fixed in WordPress 5.3 and most controls are standardized to a height of 40 pixels. Further improvements need to be explored to bring everything to 40 pixels, for example: button groups.

[afercia]

Further improvements that need to be explored:

Default 1 pixel margin on input and select elements
See https://core.trac.wordpress.org/browser/trunk/src/wp-admin/css/forms.css?rev=46559&marks=29-32#L28
I'd like to propose to remove it as it makes controls alignments troublesome at the point core itself already resets this default margin in various places. I do realize it's there for some historical reason but I don't see a good reason to keep it today and it has always been annoying, to say the least.

Standardize the controls border-radius
Form controls have different border-radius values, also in Gutenberg. Not sure there's a good reason for this. It would be nice to standardize. See ticket:34904#comment:109. This needs a design decision.

Revert the selects font size to 14 pixels
This was changed to 13 pixels in https://core.trac.wordpress.org/changeset/46356 but seems to me it's not a great improvement and makes alignments troublesome. All form controls should have the same font size as this has an impact on horizontal alignments and the computed line-height values. This needs design feedback.

Tables borders Webkit bug on Windows
Make sure to use border-collapse: collapse; on the .widefat tables to address a weird Webkit glitch that happens only on Windows. This appears to be triggered by line-height values rounding after the 5.3 admin CSS changes but it's technically unrelated and seems really a Webkit bug. Regardless, border-collapse: collapse; is standard and it's better than the current border-spacing: 0. Worth noting core already uses border-collapse: collapse; on other tables and it should have been user on .widefat tables as well since the beginning. Hat tip to @azaozz ​for reporting this on Slack.

Address edge cases

• tinymce buttons e.g. the insert link UI buttons
• improve the .page-title-action button-links
• consider to add -moz-appearance: none to the select styling to cover old Firefox versions e.g. SeaMonkey, see ticket:47477#comment:73
• in a few places in core, a super-basic form "validation" adds a red border to the invalid fields: this doesn't seem to play nicely with the new inputs styles, at least in the Customizer (see screenshot)

Please report any glitch you may have noticed after carefully comparing with WordPress 5.2 to make sure it's actually something related to the CSS changes introduced in 5.3 :)

[afercia]

48420.diff​ is a first pass to address most of the issues above and builds on top of the last patch uploaded on 47477.

[afercia]

#48429 was marked as a duplicate.

[afercia]

#48430 was marked as a duplicate.

[afercia]

Some historical background:

On WordPress 3.7, the default alignment of form controls was pretty good. It appears there was some attention paid to this kind of details. See first screenshot attached below.

With the WordPress 3.8 redesign things changed a bit: different buttons and selects heights plus some new vertical-align CSS properties made the default alignments break. In a way, this could be considered a regression.

Note: to see how form controls actually looked like in WordPress 3.7 and 3.8 they should be tested with the browsers used at that time (October 2013). It's very likely some of the CSS were intended to cover layout quirks across browsers, especially old IE versions. The screenshots attached below illustrate the rendering in latest Chrome 78.

[afercia]

Form controls alignments on WordPress 3.7

[afercia]

Form controls alignments on WordPress 3.8

[audrasjb]

Milestoning to 5.4 early (with possible backport to 5.3.x point releases)

[afercia]

Re: the border-radius: it's different between select/buttons and input fields. The inputs are slightly more "rounded" (4px), not sure if there's a specific reason for that:

It is different also in Gutenberg, where the new styles come from:

Border radius on Gutenberg WP 5.2

Border radius on Gutenberg WP 5.3

Any change will need to be ported also to Gutenberg.

[afercia]

This seems to happen only on Windows latest Firefox: the radio buttons "blue dot" isn't perfectly centered:

It appears float: left applied to the CSS generated "blue dot" is the root cause of the misalignment and as far as I see it's no longer needed.

[afercia]

#48465 was marked as a duplicate.

[jameskoster]

the small, normal, large and hero button heights would change from the WordPress 5.2 heights of 24 / 28 / 30 / 46 pixels to 26 / 30 / 32 / 46 so that the normal size is 30 pixels and the ratio between sizes is preserved

Curious how important the preservation of that ratio is?

Considering the ​proposed type scale is using multiples of 4 for all values, I wonder if the default form element height should be 28px, since 30 doesn't align with the new type scale?

Seems like the new button styles are sized:

Small: 24px;
Normal: 28px;
Large: 32px;

I think it makes sense to apply that scale to other form elements as well.

[afercia]

Sure. The proposal for a spacing system came after this ticket. I'm all for standardizing, however Small: 24px, Normal: 28px, Large: 32px feels too small. I'd just bump up everything by 4 pixels. On mobile, all sizes should "flatten" to 40 pixels except "hero" maybe.

[SergeyBiryukov]

Related: #48531

[SergeyBiryukov]

Related: #48537

[afercia]

#48537 was marked as a duplicate.

[afercia]

With regards to vertical alignments on Windows, I'd strongly recommend to consider to change the font stack, see #48423.

[GDragoN]

There are a few more issues in 5.3 I noticed:

1. input type=number has padding on the right side, so the arrows are positioned inside the control area, and not next to the border.

2. Search control on all admin side list pages (Posts, Pages...) is not properly aligned with the new button.

3. Select controls in the customizer have a wrong vertical alignment of the text inside the control (issue with the height and/or line-height).

[afercia]

Thanks everyone for the reports and feedback. As the form controls rendering varies across operating systems and browsers I'd kindly ask to add these details to the reports:

• operating system used
• browser version
• please remember to test with all plugins deactivated and a default theme activated

[afercia]

Related: #48269.

[afercia]

48420.2.diff​ builds on the previous patch and adds a few more adjustments. There are still things to address but I think the patch is ready for a first round of testing.

In the next days I'll try to summarize what the patch does and what's left to do. In the meantime, I'm at a point where a decision needs to be made. To make all form controls have by default a good vertical alignment (especially with visible labels or other text close to them) there are two possible options I can think of:

• use flexbox: however, this would require a wrapper element as a flex container thus a considerable amount of markup output should be changed, which is not ideal
• use CSS properties of the inline formatting context (inline-level boxes) like vertical-align

I'd lean towards using vertical-align: middle for all form controls as it's able to align elements and text of different heights. However, this would imply that form controls shouldn't use top or bottom margins.

Here's an example of default alignments using vertical-align: middle:

Other values like top or baseline would requireCSS adjustments on a case by case basis, which is something that would be great to avoid. One of the goals of these CSS changes is that all the WordPress admin form controls should just work out of the box and not require any further work or adjustments.

Example with vertical-align: top:

Example with vertical-align: baseline:

[dlh]

#48269 was marked as a duplicate.

[audrasjb]

Moving ths one to 5.3.1. At least to handle some first fixes in the next minor.

[azaozz]

Related: #48531.

Quick look at 48420.2.diff and similar changes that were committed in 5.3: Generally converting existing values from "hard coded" px to "dynamic" rem, %, unitless line-height, etc. is a good idea and seems "safe enough" to do. However changing these values at the same time is not a good idea and is not "safe to do" especially in a dot release :)

Ideally the conversion should happen first, be committed, (thoroughly) tested in all browsers and eventually refined and fixed if needed.

After that any changes to the values can potentially be made.

[azaozz]

Another bug/regression introduced by the CSS changes in 5.3 (that may fit in the context here) is the missing padding of <option> elements in selects and the missing bottom border/outline in some cases.

[michaelarestad]

The border radius discrepancies were brought up in ​this week's design meeting.

It sounded like folks agreed they should be consistent. There weren't great arguments for 3px. The arguments for 4px were:

• It fits nicely with the 8px grid.
• It allows for use of a 2px border radius on other elements down the road which provides more flexibility. It wouldn't be something used in the current design system, but is a good consideration.

I was all about 3px until those arguments were made and now recommend 4px. Again, it's more important that these form elements be consistent.

[afercia]

Replying to azaozz:

Another bug/regression introduced by the CSS changes in 5.3 (that may fit in the context here) is the missing padding of <option> elements in selects and the missing bottom border/outline in some cases.

I don't think the CSS changes in 5.3 touched the select options. Both issues don't seem a regression to me.

I don't see a difference in the <option> elements padding compared to 5.2. Actually, I think WordPress doesn't style the <option> elements as they can't be styled consistently across browsers.

Regarding the missing bottom border/outline, I can reproduce that in WordPress 5.2 as well, at least on Windows Firefox Chrome, though it seems to happen randomly with no apparent reason. See screenshots below (Windows Chrome / Firefox).

[afercia]

Select options in WordPress 5.2

[afercia]

Select options in WordPress 5.3

[audrasjb]

48420.2.diff - Form fields on the top of the posts list are now correctly aligned

[audrasjb]

48420.2.diff - Form fields in the import/export personal data screen are now aligned

[audrasjb]

48420.2.diff - Form fields correctly aligned in settings screen

[audrasjb]

48420.2.diff - Form fields on the top of the Privacy settings screen are now correctly aligned

[audrasjb]

Great work @afercia ! Thanks!
I tested 48420.2.diff and it fixes most of the more important alignment bug and inconsistencies / regressions which came with WP 5.3.

I'm in favor of committing these changes in 5.3.1, as a (great) first step concerning WP 5.3 bugs and small regressions.

Thanks!

[SergeyBiryukov]

In 46866:

Administration: Standardize form control height and alignment across the admin.

This improves the appearance of various form controls in the admin and addresses some visual inconsistencies in WordPress 5.3.

Props afercia, audrasjb, jameskoster, GDragoN, azaozz, michaelarestad, murgroland, SamuelFernandez, chetan200891, veminom, dlh.
Fixes #48420.

[SergeyBiryukov]

In 46867:

Administration: Standardize form control height and alignment across the admin.

This improves the appearance of various form controls in the admin and addresses some visual inconsistencies in WordPress 5.3.

Props afercia, audrasjb, jameskoster, GDragoN, azaozz, michaelarestad, murgroland, SamuelFernandez, chetan200891, veminom, dlh.
Merges [46866] to the 5.3 branch.
Fixes #48420.

[afercia]

If no objections, I'd like to propose to make this ticket a task that spans over the next minor releases and maybe also to the 5.4 milestone.

The work on form controls improvements will need further iteration and I'm not sure creating a new ticket would be the best path forward. There's a lot of context on this ticket that would be good to have for future work on the form controls. Some of hte things that will need to be addressed are, for example:

• making the border radius consistent, see design feedback on comment:28
• standardize vertical alignment, see comment:20
• implement the 8 pixels based "grid" from ​the spacing system proposal on Make
• etc.

[SergeyBiryukov]

Replying to afercia:

If no objections, I'd like to propose to make this ticket a task that spans over the next minor releases and maybe also to the 5.4 milestone.

Sounds good :)

[azaozz]

Replying to afercia:

If no objections, I'd like to propose to make this ticket a task
...
The work on form controls improvements will need further iteration and I'm not sure creating a new ticket would be the best path forward.

Don't think it is a good idea to mix many bugfuxes and enhancements on a single "enormous" ticket. This leads to confusion what was done and why, poor tracking of changes and reviews and ultimately leads to inconsistent tracking of changes and omissions.

• making the border radius consistent, see design feedback on comment:28
• standardize vertical alignment, see comment:20
• implement the 8 pixels based "grid" from

The first is a pretty substantial bugfix that will require quite a bit of testing and reviews, mostly regarding the visual design.

The second sounds like an enhancement that will need further testing/consideration. The vertical-align: middle may work for many browsers and in many cases, but doesn't work everywhere for everything.

The third is a very large undertaking that will (probably) need a feature project in order to be completed properly. It will need a lot of iterating, testing and reviews as the potential to "break" existing layout seems large. Looks like it may even span over several releases.

Thinking that "lumping all of this together" is a bad idea that will prevent proper development.

Also, initially this ticket was for the 5.4 milestone. I was brought to the 5.3.1 milestone in an attempt to fix some of the CSS regressions introduced in 5.3. This is now complete and the ticket was closed. All remaining bugfixes, enhancements and new features should be moved to new tickets.

[SergeyBiryukov]

Related: #48928

[audrasjb]

Closing as fixed for now, to keep the milestone clear before releasing 5.3.1 RC 2.

(also adding missing has-dev-note keyword)

[SergeyBiryukov]

Link to the dev note, for reference: ​https://make.wordpress.org/core/2019/12/11/admin-form-controls-height-and-alignment-standardization-in-wordpress-5-3-1/

[dlh]

#45147 was marked as a duplicate.

[afercia]

In 48362:

Administration: Fix typo in forms.css after [46866].

A stray e made browsers ignore a CSS ruleset preventing select elements from changing color on hover.

Props ryokuhi.
See #48420.
Fixes #50580.