WordPress.org

Make WordPress Core

Opened 6 weeks ago

Last modified 3 hours ago

#48420 accepted defect (bug)

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

Reported by: afercia Owned by: audrasjb
Milestone: 5.3.1 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots 5-3-admin-css-changes has-patch commit needs-dev-note
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 (11)

48420.diff (13.6 KB) - added by afercia 6 weeks ago.
alignments wp 3.7.png (69.6 KB) - added by afercia 6 weeks ago.
Form controls alignments on WordPress 3.7
alignments wp 3.8.png (72.5 KB) - added by afercia 6 weeks ago.
Form controls alignments on WordPress 3.8
48420.2.diff (14.5 KB) - added by afercia 2 weeks ago.
select-border-padding.png (21.7 KB) - added by azaozz 9 days ago.
select option 5.2.png (48.0 KB) - added by afercia 36 hours ago.
Select options in WordPress 5.2
select option 5.3.png (45.7 KB) - added by afercia 36 hours ago.
Select options in WordPress 5.3
Capture d’écran 2019-12-05 à 22.34.35.png (125.5 KB) - added by audrasjb 26 hours ago.
48420.2.diff - Form fields on the top of the posts list are now correctly aligned
Capture d’écran 2019-12-05 à 22.36.54.png (98.5 KB) - added by audrasjb 26 hours ago.
48420.2.diff - Form fields in the import/export personal data screen are now aligned
Capture d’écran 2019-12-05 à 22.37.26.png (101.4 KB) - added by audrasjb 26 hours ago.
48420.2.diff - Form fields correctly aligned in settings screen
Capture d’écran 2019-12-05 à 22.38.01.png (131.9 KB) - added by audrasjb 26 hours ago.
48420.2.diff - Form fields on the top of the Privacy settings screen are now correctly aligned

Download all attachments as: .zip

Change History (43)

#1 @afercia
6 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 6 weeks ago by afercia (previous) (diff)

@afercia
6 weeks ago

#2 @afercia
6 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
6 weeks ago

#48429 was marked as a duplicate.

#4 @afercia
6 weeks ago

#48430 was marked as a duplicate.

#5 @afercia
6 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
6 weeks ago

Form controls alignments on WordPress 3.7

@afercia
6 weeks ago

Form controls alignments on WordPress 3.8

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


6 weeks ago

#7 @audrasjb
6 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
6 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
6 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
5 weeks ago

#48465 was marked as a duplicate.

#11 @jameskoster
5 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
4 weeks 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 4 weeks ago by afercia (previous) (diff)

#15 @afercia
3 weeks ago

#48537 was marked as a duplicate.

#16 @afercia
3 weeks ago

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

#17 @GDragoN
3 weeks 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
3 weeks 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

#19 @afercia
2 weeks ago

Related: #48269.

@afercia
2 weeks ago

#20 @afercia
2 weeks ago

  • Keywords has-patch needs-testing added; needs-patch removed

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:

http://cldup.com/fXt9NF2N54.png

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:

http://cldup.com/P4d3G655rg.png

Example with vertical-align: baseline:

http://cldup.com/8f-DqeFX6I.png

#21 @dlh
2 weeks ago

#48269 was marked as a duplicate.

#22 @audrasjb
2 weeks ago

  • Milestone changed from 5.4 to 5.3.1
  • Owner set to audrasjb
  • Status changed from new to reviewing

#23 @audrasjb
2 weeks ago

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

#24 @azaozz
9 days ago

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.

Last edited 9 days ago by azaozz (previous) (diff)

#25 follow-up: @azaozz
9 days ago

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.

Last edited 9 days ago by azaozz (previous) (diff)

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


3 days ago

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


2 days ago

#28 @michaelarestad
2 days ago

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.

#29 in reply to: ↑ 25 @afercia
36 hours ago

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

Last edited 36 hours ago by afercia (previous) (diff)

@afercia
36 hours ago

Select options in WordPress 5.2

@afercia
36 hours ago

Select options in WordPress 5.3

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


31 hours ago

@audrasjb
26 hours ago

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

@audrasjb
26 hours ago

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

@audrasjb
26 hours ago

48420.2.diff - Form fields correctly aligned in settings screen

@audrasjb
26 hours ago

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

#31 @audrasjb
26 hours ago

  • Keywords commit added; early needs-testing removed
  • Status changed from reviewing to accepted

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!

Last edited 26 hours ago by audrasjb (previous) (diff)

#32 @audrasjb
3 hours ago

  • Keywords needs-dev-note added
Note: See TracTickets for help on using tickets.