WordPress.org

Make WordPress Core

Opened 5 months ago

Closed 4 months ago

Last modified 4 months ago

#48420 closed defect (bug) (fixed)

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-dev-note
Focuses: ui Cc:

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 5 months ago.
alignments wp 3.7.png (69.6 KB) - added by afercia 5 months ago.
Form controls alignments on WordPress 3.7
alignments wp 3.8.png (72.5 KB) - added by afercia 5 months ago.
Form controls alignments on WordPress 3.8
48420.2.diff (14.5 KB) - added by afercia 4 months ago.
select-border-padding.png (21.7 KB) - added by azaozz 4 months ago.
select option 5.2.png (48.0 KB) - added by afercia 4 months ago.
Select options in WordPress 5.2
select option 5.3.png (45.7 KB) - added by afercia 4 months ago.
Select options in WordPress 5.3
Capture d’écran 2019-12-05 à 22.34.35.png (125.5 KB) - added by audrasjb 4 months 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 4 months 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 4 months 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 4 months 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 (53)

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

@afercia
5 months ago

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

#48429 was marked as a duplicate.

#4 @afercia
5 months ago

#48430 was marked as a duplicate.

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

Form controls alignments on WordPress 3.7

@afercia
5 months ago

Form controls alignments on WordPress 3.8

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


5 months ago

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

#48465 was marked as a duplicate.

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

#15 @afercia
5 months ago

#48537 was marked as a duplicate.

#16 @afercia
5 months ago

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

#17 @GDragoN
5 months 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 months 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
4 months ago

Related: #48269.

@afercia
4 months ago

#20 @afercia
4 months 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
4 months ago

#48269 was marked as a duplicate.

#22 @audrasjb
4 months ago

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

#23 @audrasjb
4 months ago

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

#24 @azaozz
4 months 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 4 months ago by azaozz (previous) (diff)

#25 follow-up: @azaozz
4 months 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 4 months ago by azaozz (previous) (diff)

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


4 months ago

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


4 months ago

#28 @michaelarestad
4 months 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
4 months 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 4 months ago by afercia (previous) (diff)

@afercia
4 months ago

Select options in WordPress 5.2

@afercia
4 months ago

Select options in WordPress 5.3

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


4 months ago

@audrasjb
4 months ago

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

@audrasjb
4 months ago

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

@audrasjb
4 months ago

48420.2.diff - Form fields correctly aligned in settings screen

@audrasjb
4 months ago

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

#31 @audrasjb
4 months 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 4 months ago by audrasjb (previous) (diff)

#32 @audrasjb
4 months ago

  • Keywords needs-dev-note added

#33 @SergeyBiryukov
4 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#34 @SergeyBiryukov
4 months ago

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.

#35 follow-ups: @afercia
4 months ago

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:

#36 in reply to: ↑ 35 @SergeyBiryukov
4 months ago

  • Milestone changed from 5.3.1 to 5.4
  • Resolution fixed deleted
  • Status changed from closed to reopened

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

#37 @SergeyBiryukov
4 months ago

  • Keywords has-patch commit removed

#38 in reply to: ↑ 35 @azaozz
4 months ago

  • Keywords close added
  • Milestone changed from 5.4 to 5.3.1

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

Last edited 4 months ago by azaozz (previous) (diff)

#40 @audrasjb
4 months ago

  • Keywords has-dev-note added; needs-dev-note close removed
  • Resolution set to fixed
  • Status changed from reopened to closed

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

(also adding missing has-dev-note keyword)

#42 @dlh
4 months ago

#45147 was marked as a duplicate.

Note: See TracTickets for help on using tickets.