WordPress.org

Make WordPress Core

Opened 4 weeks ago

Last modified 5 days ago

#48420 new defect (bug)

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

Reported by: afercia Owned by:
Milestone: 5.4 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots needs-patch 5-3-admin-css-changes early
Focuses: ui Cc:
PR Number:

Description

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):

http://cldup.com/CoNas3RNxH.png

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:

http://cldup.com/CPhqHu1x1p.png

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.

Attachments (3)

48420.diff (13.6 KB) - added by afercia 4 weeks ago.
alignments wp 3.7.png (69.6 KB) - added by afercia 3 weeks ago.
Form controls alignments on WordPress 3.7
alignments wp 3.8.png (72.5 KB) - added by afercia 3 weeks ago.
Form controls alignments on WordPress 3.8

Download all attachments as: .zip

Change History (21)

#1 @afercia
4 weeks ago

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)

http://cldup.com/QX-nv0pFB2.png

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 :)

Last edited 4 weeks ago by afercia (previous) (diff)

@afercia
4 weeks ago

#2 @afercia
4 weeks ago

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

#3 @afercia
3 weeks ago

#48429 was marked as a duplicate.

#4 @afercia
3 weeks ago

#48430 was marked as a duplicate.

#5 @afercia
3 weeks ago

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
3 weeks ago

Form controls alignments on WordPress 3.7

@afercia
3 weeks ago

Form controls alignments on WordPress 3.8

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


3 weeks ago

#7 @audrasjb
3 weeks ago

  • Keywords early added
  • Milestone changed from Awaiting Review to 5.4

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

#8 @afercia
3 weeks ago

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:

http://cldup.com/WkyyFRZtC2.png

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

Border radius on Gutenberg WP 5.2

http://cldup.com/yXtXkN8pDF.png

Border radius on Gutenberg WP 5.3

http://cldup.com/AoiZRHRfVG.png

Any change will need to be ported also to Gutenberg.

#9 @afercia
3 weeks ago

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

http://cldup.com/z7JjspRM6E.png

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.

#10 @afercia
3 weeks ago

#48465 was marked as a duplicate.

#11 @jameskoster
2 weeks ago

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.

#12 @afercia
12 days ago

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.

Last edited 11 days ago by afercia (previous) (diff)

#15 @afercia
6 days ago

#48537 was marked as a duplicate.

#16 @afercia
6 days ago

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

#17 @GDragoN
5 days ago

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.
  1. Search control on all admin side list pages (Posts, Pages...) is not properly aligned with the new button.
  1. Select controls in the customizer have a wrong vertical alignment of the text inside the control (issue with the height and/or line-height).

#18 @afercia
5 days ago

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
Note: See TracTickets for help on using tickets.