Admin form controls height and alignment standardization in WordPress 5.3.1

WordPress 5.3 introduced some notable Admin CSS changes to improve administration accessibility and consistency with the block editor.

These changes made more obvious that form controls heights and alignments were not consistent across WP Admin.

Before WordPress 5.3, there were already some inconsistencies between form controls. For reference, WordPress 5.2 form controls various alignments and heights are grouped in the screenshot below:

Form controls alignment and height inconsistencies in WordPress 5.2

WordPress 5.3 Admin CSS changes brought more attention to those general inconsistencies on form controls. And several users and contributors reported these inconsistencies as regressions from 5.3.

Example of form controls inconsistencies in WordPress 5.3

Although these inconsistencies cannot be considered as regressions from 5.3 since they existed before 5.3 Admin CSS changes, WordPress 5.3.1 introduces some fixes on heights and alignments.


WordPress 5.3.1 changes include:

  • Standardized height basis of 30px for all form controls
  • Consistent line height basis of 30px across the interface
  • 14px font size basis for select controls option text
  • Remove various top/bottom margin and padding

These changes are part of a continuous effort to improve styling and consistency of all form controls in the WordPress admin pages. In general, plugin authors and WordPress developers are encouraged to:

  • remove any fixed height: flexible heights are now the WordPress recommended standard to allow form controls to better scale with text zoom
  • remove any custom top and bottom padding values
  • remove any custom line-height value
  • remove any custom min-height value
  • update custom focus/hover styles on custom UI components to match the new WordPress focus/hover styles

For full details about these changes, see the related changeset on WordPress Trac. WordPress developers and plugin authors may also want to visit the related Trac ticket: #48420

#5-3-1, #core-css, #dev-notes

Alternate color schemes changes in WordPress 5.3.1

WordPress 5.3 added some noteworthy CSS changes to WordPress Admin. These changes also impacted alternate color schemes, especially concerning secondary buttons.

Indeed, secondary button borders unexpectedly inherited their scheme’s primary color, which resulted in arguable visual aspect and poor readability for most color schemes.

“Blue” alternate color scheme in WordPress 5.3
“Coffee” alternate color scheme in WordPress 5.3
“Midnight” alternate color scheme in WordPress 5.3

A bug also occurred on :active state, where the background color of the button was quite the same than the text color.

On the right: secondary button with :active state on “Blue” color scheme in WordPress 5.3
On the right: secondary button with :active state on “Midnight” color scheme in WordPress 5.3

WordPress 5.3.1 will fix these issues by unifying WP-Admin secondary buttons for all alternate color schemes.

Secondary button styles will be the same for all bundled alternate color schemes. This change also fixes the :active state CSS issue.

Please note this change also introduces some hardcoded colors for both gray borders and texts. Plugin authors who provide specific support for alternate color schemes can use these new hardcoded colors.

New secondary button CSS/Sass styles in WP 5.3.1:

.button {
	border-color: #7e8993;
	color: #32373c;

.button:hover {
	border-color: darken( #7e8993, 5% );
	color: darken( #32373c, 5% );

.button:focus {
	border-color: #7e8993;
	color: darken( #32373c, 5% );
	box-shadow: 0 0 0 1px #32373c;

See /wp-admin/css/colors/_admin.scss.

New CSS styles for secondary buttons in alternate color schemes:

Secondary buttons in WordPress 5.3.1
“Midnight” alternate color scheme in WP 5.3.1
“Coffee” alternate color scheme in WP 5.3.1

For reference, see the related Trac tickets: #48585 and #48598.

#5-3-1, #accessibility, #core-css, #dev-notes

Twenty Twenty: animated scroll changes in WordPress 5.3.1

In WordPress 5.3, Twenty Twenty new bundled theme added smooth scroll animations to anchor links. These animations were handled by native JavaScript and it caused several issues, mentioned in the following Trac tickets and GitHub issues:

  • #48763 – Twenty Twenty: SmoothScroll is broken
  • #48551 – Twenty Twenty: Replace JS-based smooth scroll with CSS
  • #48866 – TwentyTwenty: Paginated comments don’t work
  • GitHub issue 476 – Consider removing JS-based smooth scroll

Additionally to the multiple issues listed in the above tickets, JavaScript-based scroll animations add a bunch of relatively complex JS code, override natural anchor behavior and may interfere with how specific user agents handle in-page scrolling.

In WordPress 5.3.1, the current smooth scroll JavaScript implementation will be replaced with “scroll-behavior” CSS property.

This change fixes the issues encountered with the current JavaScript implementation, and also includes an accessibility enhancement by using prefers-reduced-motion: reduce media query property for users that have opted in to reduced motion in their browser settings.

For further explanation on this media query, see Mozilla Developer Network documentation.

Browsers that don’t support scroll-behavior CSS property will fallback to default HTML anchor behavior. For reference, see full browsers support for this CSS property on MDN.

New CSS scroll animation implementation in Twenty Twenty:

html {
    scroll-behavior: smooth;
@media (prefers-reduced-motion: reduce) {
    html {
        scroll-behavior: auto;

Developers are able to remove scroll-behavior effect on specific elements by using a class CSS selector, as follows:

.disable-smooth-scrolling {
    scroll-behavior: auto;

For reference, see the related changeset in 5.3.1 branch.

#5-3-1, #accessibility, #bundled-theme, #core-css, #dev-notes, #twentytwenty

Devchat summary: November 27, 2019

The year is winding down!

@francina led the chat; @marybaum here taking notes on a holiday-travel schedule.

20 people announced their presence – of course somewhere around 30K are members, and we could ALL have been watching. The more the merrier!

The chat worked from this agenda.


Next minor: 5.3.1

The announcements were all about the next minor, WordPress 5.3.1.

@justinahinon and I (@marybaum) announced that he would move the Thursday bug scrub to Friday so folks in the US could join in without interrupting their Thanksgiving plans.

After some discussion, @azaozz suggested ad hoc bug scrubs every day until release on December 11. He got active emoji support from five people, and then @audrasjb volunteered to host a bug scrub every day this week (the week of December 2).

Highlighted Posts

@francina called the group’s attention to four conversations.

Got opinions? Especially if your feelings are strong, now’s the time to get over there and share your views:

  1. Recap from last week “Regular” chat (edited) 3:15 PM
  2. Recap from last week “After Hour” chat (edited) 3:15 PM
  3. Tons of good feedback about the 5.3 release (edited) 3:16 PM
  4. And tentative release for 2020-2021 (edited)

And you can always come to devchat, Wednesdays at 21:00 UTC. Find the agenda here, 24 hours in advance.

Calls from Component Maintainers

@francina opened the Call with this wide-ranging intro:

Do we have news from components? Do we have abandoned components that someone wants to adopt? (edited) 3:22 PM

Do we have components that are struggling with the amount of work and need more hands on deck? How can we come together as a community to recruit? (edited) 

See the discussion starting here.

What followed was a general clarification of the difference between a component and a focus, thanks to @sergeybiryukov, who linked to two posts that add some detail.

(I’m listing them in reverse order, so you can read from the general to the specific):

@isabel_brison‘s post introducing the idea of a focus versus a component.

And this post, introducing the Core-CSS group in Slack.

As that discussion ended, @isabel_brison offered to write a followup post, which you can find here.

What are our goals in publishing?

@francina handed the (virtual) mic to @joyously, whose comment on the agenda for this chat asked the group to address goals in publishing.

Essentially, @joyously reminded us that publishers – our users [and as I was trained to think of such folks ~30 years ago, our customers, both internal and external] create content that is going to go more places than just a browser: in emails, feed readers and more. And those environments vary radically in their support for CSS and JS.

In her words:

I am concerned that the trend is toward content that looks good only in a web browser (with JS and CSS) and not good anywhere else.


See the rest of the discussion in chat here.

A highlight: @francina linked to this post on Smashing Magazine, that looks at another facet of this issue.

And be on the lookout for more blog posts addressing the topic, so you can add your thoughts.

#components, #core-css, #devchat, #focuses

New CSS focus in Core

Core has a new focus! As a next step after the birth of the #core-css channel, we now have a matching CSS focus, and tickets are starting to be added to it. You can find existing tickets here:!closed&focuses=~css

How to use it?

Quoting from the post that introduced the focuses:

“Focuses are about broad concepts and help break tickets down by specialties and skills, rather than functional areas of core”

With that in mind, the CSS focus should include tickets about

CSS architecture and tooling,

New features that need custom styling,

CSS bugs

and anything else that affects CSS in Core.

Keep in mind that a ticket can have more than one focus, so it’s worth adding the CSS focus where it makes sense.

Here’s how it works:

You can add a focus in the new-ticket form, or in the Modify Ticket section of an existing ticket. Choose the appropriate ones from a list at the bottom right corner of the form:

New ticket form showing Focuses on bottom right corner.

Click on a focus to add it to the ticket.

Dev Chat Summary: November 13, 2019

@francina led this week’s dev chat – the last one of the 5.3 release cycle – see the agenda here.

For the full transcript, see the Slack archive here.

Your faithful reporter: @amykamala. Let’s get going!


@francina opened Announcements with the release of WordPress 5.3, which went live on November 12, 2019!

She congratulated everyone, NOT just the folks active in the chat, on an amazing job. Several Core committers were especially pleased that 5.3 came in on schedule (🎉) with the biggest group of contributors ever.

Here are a few statistics:

  • 12 weeks of development
  • A release squad with nine focus leads, covering every relevant component that got an update
  • 645 contributors
  • 658 bugfixes
  • A new default theme, Twenty Twenty
  • Lots of fun and new friends made
  • And much, much more!

Before release the squad counted at least 153 user-experience enhancements.

Highlighted Posts

The annual WordPress survey is open! Your feedback is not just appreciated – it’s vital to the future of WordPress. So please fill it out and share it everywhere you can think of.

Tanking the floor for a moment, @chanthaboune told the group this survey is new – not the same as last year – and is broader. Whether you’re a contributor, designers, developers, users or hosts, please participate!

Again, please share the survey with anyone who touches WordPress in any way.

5.3 Housekeeping

Big thanks to everyone who has helped with testing so far! If that includes you, please keep testing and report any issues, concerns or enhancement ideas in a comment on Trac.

That’s how WordPress gets better and you get to shepherd your best ideas through the process.

Need a refresher on how it works? Here’s an outline of the post-release process.

@francina wrapped the discussion with a note that in the next few weeks the release leads will open a call for retrospective. Want to share some honest, constructive feedback? That’ll be your chance!

5.3 Housekeeping Calls from component maintainers

@francina opened the floor for component maintainers to bring up topics for discussion. These are the components.

@marybaum said “I love that we have a #core-css channel. Does that mean Core CSS is a component?”

@peterwilsoncc replied, “it’s closer to a focus than a component. Tickets can still be assigned to the affected component, eg Admin, Themes, etc. “

@sergey asked “If we have a `javascript` focus, should we add one for CSS as well? 

After a few more comments from folks, @francina reminded all 30,000-plus potential attendees that we don’t make final decisions in devchat.

She asked the folks talking about CSS to follow this process:

  • Make a proposal on the Core blog
  • Discuss
  • Come to a conclusion
  • Act

Here are the reports from other component maintainers:

@williampatton: “Themes component is looking good. Prepping for next release.” 

@peterwilsoncc: “From the security team, now we have a Travis CI account that allows for private repos, we have the security tests running regularly. It should make it easier to find out if they’re passing during the release process.” and went on to ask @sergey if it was possible to add it to Trac.

@garret-eclipse: “In the privacy component @rogierlankhorst has started work on a consent api.

Open Floor

@mensmaximus asked whether “we ever change the user management screen to a tabbed interface. What is the current state and what do core devs think?”

@williampatton started with a general reply: “There are lots of thoughts on redesign for user management, but lots of ideas mean lots of decisions [making it] hard to reach agreement.”

A lively discussion followed. Hopefully the WordPress world will see some new ideas for an even more usable Admin experience!

(Ed. note: The UX discussion and the conversation below, about jQuery, happened at the same time, and you’ll see the comments jump from one to the other. Still, imo, both are worth your time and effort to decipher!)

@enrico.sorcinelli has “noticed that Juery’s `$` is no longer globally defined in admin.” That’s made some of their client sites cause issues with users’ code.

@clorith answered, “The jQuery `$` being globally available was a bug.” That bug got fixed in one of the JS updates in 5.3.

“Although it’s not ideal, reports of issues are fewer than expected, and the code errors would be within the plugin code,” @clorith continued, adding, “I tend to lean towards leaving it being the right thing.” 

Here’s the ticket they’re talking about and the full discussion, including some observations on the future of jQuery.

@clorith noticed two items leading the pack of recurring issues, 24 hours in:

  • The update to add_submenu_page gives doing-it-wrong errors. We knew this, but devs weren’t prepared for users to have debugging enabled. 
  • The change to spread operators had plugins breaking, because things like custom walkers had dependencies on the previous operators.

See the full discussion starting at the link above. (Ed. note: this highlighted test is the same link.)

@pbiron asked if anyone had reported problems with the new big-images or rotate-on-upload features. 

@clorith and others noted very few issues.

#5-3, #devchat, #meeting-notes