#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):
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.
Attachments (11)
Change History (54)
#2
@
5 years 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.
#5
@
5 years 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.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
5 years ago
#7
@
5 years 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
@
5 years 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:
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.
#11
@
5 years 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
@
5 years 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.
#16
@
5 years ago
With regards to vertical alignments on Windows, I'd strongly recommend to consider to change the font stack, see #48423.
#17
@
5 years ago
There are a few more issues in 5.3 I noticed:
- input type=number has padding on the right side, so the arrows are positioned inside the control area, and not next to the border.
- Search control on all admin side list pages (Posts, Pages...) is not properly aligned with the new button.
- 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
@
5 years 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
#20
@
5 years 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
:
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
:
#22
@
5 years ago
- Milestone changed from 5.4 to 5.3.1
- Owner set to audrasjb
- Status changed from new to reviewing
#24
@
5 years 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.
#25
follow-up:
↓ 29
@
5 years 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.
This ticket was mentioned in Slack in #design by melchoyce. View the logs.
5 years ago
This ticket was mentioned in Slack in #design by melchoyce. View the logs.
5 years ago
#28
@
5 years 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
@
5 years 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).
This ticket was mentioned in Slack in #core by audrasjb. View the logs.
5 years ago
@
5 years ago
48420.2.diff - Form fields on the top of the Privacy settings screen are now correctly aligned
#31
@
5 years 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!
#35
follow-ups:
↓ 36
↓ 38
@
5 years 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:
- 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.
#36
in reply to:
↑ 35
@
5 years 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 :)
#38
in reply to:
↑ 35
@
5 years 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.
#40
@
5 years 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)
#41
@
5 years ago
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/
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 currentborder-spacing: 0
. Worth noting core already usesborder-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
.page-title-action
button-links-moz-appearance: none
to the select styling to cover old Firefox versions e.g. SeaMonkey, see ticket:47477#comment:73Please 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 :)