Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#48269 closed defect (bug) (duplicate)

WordPress beta 5.3 - Customizer - Height of input and select are not same.

Reported by: veminom's profile veminom Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.3
Component: Customize Keywords: needs-post-mortem close
Focuses: ui, accessibility Cc:

Description

After testing WordPress 5.3 Beta I found that the height of the input and select in the customizer is not equal. It looks like in beta version we have added increased the min-height of the input from 28px to 30px.

Please see the screenshot below:
https://cl.ly/e82bc0c16da1

And the height of the select is still the same 28px.

Please see the screenshot below:
https://cl.ly/c441e5c20883

I think we should have a similar height for both the select and input fields. ( either 30px or 28px )

Change History (13)

#1 follow-up: @dlh
5 years ago

  • Component changed from General to Customize
  • Keywords reporter-feedback added; needs-patch removed
  • Severity changed from major to normal
  • Version trunk deleted

Hi @veminom, and welcome to WordPress Trac!

I don't see a min-height applied to input fields in the Customizer in WordPress 5.2; from what I can see, the input and select elements have different heights in 5.2, albeit not the same as those in 5.3.

So, I'm not sure I see a regression. Separately, what would be the reasons for making them the same?

#2 in reply to: ↑ 1 @veminom
5 years ago

Hello @dlh,

Thank you for your response.

I don't see a min-height applied to input fields in the Customizer in WordPress 5.2; from what I can see, the input and select elements have different heights in 5.2, albeit not the same as those in 5.3.

  • I'm sorry for not describing it properly. The issue seems to be with the input field type number.

When I checked the input field type number, the below is the CSS I found for the input field type number:

WordPress 5.2:

Input ( type - number ) - 

http://localhost/wp-new/wp-admin/css/customize-controls.css?ver=5.2.4

.customize-control input[type="text"],
.customize-control input[type="password"],
.customize-control input[type="email"],
.customize-control input[type="number"],
.customize-control input[type="search"],
.customize-control input[type="tel"],
.customize-control input[type="url"] {
	width: 100%;
	line-height: 1.3;
	margin: 0;
}

http://localhost/wp-new/wp-admin/css/forms.css?ver=5.2.4

/* Vertically align the number selector with the input. */
input[type="number"] {
	height: 28px;
	line-height: 1;
}

In the above CSS, the height of 28px is applying to the input type number.

There seems to be no default WP theme with number field in it so I opened the Elements(HTML) editor of the page and renamed input type to number from text.

Please see the screenshot below:
https://cl.ly/49943d87bb60

Now, for field select in WordPress 5.2 there is height: 28px;.

WordPress 5.2:

Select -

http://localhost/wp-new/wp-admin/css/customize-controls.css?ver=5.2.4

.customize-control select {
    width: 100%;
    height: 28px;
    line-height: 2;
}

Please see the screenshot below:
https://cl.ly/38c1c0dbd7a6

So it looks like the height for both Input type number and Select is same that is 28px in WordPress 5.2.

# Now, coming to WordPress 5.3

Same input type field number CSS:

WordPress 5.3:

Input ( type - number ) -

http://localhost/wp-beta-test/wp-admin/css/forms.css?ver=5.3-RC1-46558

input[type="text"],
input[type="password"],
input[type="date"],
input[type="datetime"],
input[type="datetime-local"],
input[type="email"],
input[type="month"],
input[type="number"],
input[type="search"],
input[type="tel"],
input[type="time"],
input[type="url"],
input[type="week"] {
	padding: 0 8px;
	/* inherits font size 14px */
	line-height: 2; /* 28px */
	/* Only necessary for IE11 */
	min-height: 30px;
}

Here the min-height of 30px is applied to the input field type number.

Please see the screenshot below:
https://cl.ly/d9a77327d738

And for select field the below CSS is getting applied:

WordPress 5.3:

Select -

http://localhost/wp-beta-test/wp-admin/css/customize-controls.css?ver=5.3-RC1-46558

.customize-control select {
    width: 100%;
    height: 28px;
    line-height: 2;
}

Please see the screenshot below:
https://cl.ly/f753bab78a23

Here the height is applied to the select field of 28px due to which the height of Input type number is 2 pixels more than that of Select field.


In my opinion, both the heights should be the same.

what would be the reasons for making them the same?

  • We should keep all the fields height the same as they were before. This new change of min-height 30 to input type number field is creating some UI issues because some of the themes use Input type number field with Select field in the same line which creates the height problem.

For example, please check the Astra:

Customizer -> Global -> Typography -> Headings ->

Please see the screenshot below:
https://cl.ly/bf53dece088f

In the above screenshot you can see that the height for input type number and select is different in WP 5.3 beta version while it is equal in WP 5.2 version

Please let me know your thoughts.

Thank you!

Replying to dlh:

Hi @veminom, and welcome to WordPress Trac!

I don't see a min-height applied to input fields in the Customizer in WordPress 5.2; from what I can see, the input and select elements have different heights in 5.2, albeit not the same as those in 5.3.

So, I'm not sure I see a regression. Separately, what would be the reasons for making them the same?

#3 @dlh
5 years ago

  • Focuses accessibility added
  • Keywords dev-feedback added; reporter-feedback removed
  • Milestone changed from Awaiting Review to 5.3
  • Version set to trunk

Thanks for your detailed explanation, @veminom!

I wonder whether I could ask for help from the accessibility team in understanding the correct approach here.

.customize-control select is still set to height: 28px;. Based on the recent CSS changes, it seems like that should be changed to min-height: 28px;

However, other inputs have been changed to min-height: 30px in the recent CSS changes, and the dev note published at https://make.wordpress.org/core/2019/10/18/noteworthy-admin-css-changes-in-wordpress-5-3/ says that selects should now have a min-height: 30px;. But, as far as I can see, they're 28px.

So:

  1. What is the correct update to the Customize CSS?
  1. Is it intentional that the select min-height be different than inputs?

Adding this to the 5.3 milestone and adding the #accessibility focus for visibility.

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


5 years ago

#5 @afercia
5 years ago

  • Keywords close added; dev-feedback removed
  • Milestone changed from 5.3 to Future Release

Thanks for the report :) These are known issues and will be addressed soon, hopefully in the next minor release.

Worth noting on #47477 there is a last patch (not committed in trunk because we ran out of time) that aims to make all the form controls have a default minimum height of 30 pixels. This would solve long standing issues with form controls alignments that exist since a good number of years in core.

Please refer to #47477: starting from comment 67 you will see some screenshots that outline how the lack of a standard height is everywhere in WordPress 5.2 and previous versions.

Additionally, the <select> elements in the Customizer are still using the "old" style and they look different from the new ones in the rest of the WP admin. This is planned to be fixed soon as well.

As outlined in the Make post that details the admin CSS changes this is a work in progress, pretty much like anything in WordPress Core :)

The design and accessibility teams will take care of creating a new ticket to detail all the further improvements that need to be addressed in the next release cycle.

Any feedback on the new ticket is always very appreciated: I'll take care of referencing the new ticket here.

If no objections, it would be best to close this ticket pending the creation of the new one.

#6 @azaozz
5 years ago

@afercia is there a reason not to fix this specific case in 5.3?

Yes, we are near RC2, but that change/regression was introduced just few days ago, far too late to catch and fix all the "consequences" :)

#7 @afercia
5 years ago

@azaozz I recommended more than once to commit https://core.trac.wordpress.org/attachment/ticket/47477/47477.11.diff and I was told it was not possible because we're in RC :)

That patch makes all the form controls have a minimum height of 30 pixels. To fully address the the select elements in the Customizer, we'd need to change (or add) a selector. I'm not sure fixing this specific case within the Customizer makes sense while there are other similar cases in the rest of the admin. Open to suggestions :) Can refine and commit the patch from #47477 in a relatively short time.

Version 0, edited 5 years ago by afercia (next)

#8 @azaozz
5 years ago

  • Keywords needs-post-mortem added; close removed

#9 @afercia
5 years ago

in the recent CSS changes, and the dev note published at https://make.wordpress.org/core/2019/10/18/noteworthy-admin-css-changes-in-wordpress-5-3/ says that selects should now have a min-height: 30px;.

Ah yes, good catch! I see the Make post reports a code snippet for the select that appears to be out of date. /Cc @audrasjb

#10 @dlh
5 years ago

@afercia Thanks for providing that context and pointing us towards the history in #47477.

I'll leave this ticket open for the moment while a decision is made about the minimum-height patch and whether any of it could be ported to the Customizer in 5.3, but I trust the judgment of the accessibility and design teams about whether to fold this issue into a larger ticket to be created soon.

#11 @afercia
5 years ago

Thanks @dlh. For what is worth, I was in favor of merging also the last patch from #47477 even if a bit late in the release cycle.

#12 @afercia
5 years ago

  • Keywords close added

Worth noting there's now #48420 that aims to standardize heights and alignments of all form controls. Even though this ticket was created before, I'd lean towards closing it and move the conversation to #48420 if no objections. On #48420 there's a broader approach aiming to adjust all the pending cases.

#13 @dlh
5 years ago

  • Milestone Future Release deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Closing in favor of #48420. @veminom, please don't hesitate to provide feedback there!

Note: See TracTickets for help on using tickets.