New select CSS in v5.3-RC1 overlaps text

[jsmoriss]

If the new select box is shorter than the selected option text, the drop-down transparent image overlaps the text and the resulting image is confusing.

[jsmoriss]

It looks like changing the default WP select padding value will create this problem.

This works fine:

padding: 4px 24px 4px 8px;

This does not:

padding: 2px;

[desrosj]

Thanks for the report, @jsmoriss!

I am moving this to the 5.3 milestone for some visibility and investigation.

[joyously]

The arrow is a background image. So the field has to be big enough to show the text, and the arrow beside it (like with padding on the language appropriate side).

[jsmoriss]

Browsers already offer a drop-down arrow - I don't know why WP would re-create that functionality, and in doing so, make selects vulnerable to all kinds of CSS padding issues like this one.

js.

[joyously]

I agree wholeheartedly, and was surprised to see this in an accessibility change.

[adhitya03]

I have done some investigation and I think this issue come from your plugin's CSS. For example, In "Privacy Settings", I made a very long page's title and choose it to be privacy police's page, so select box is shorter than the selected option text but the drop-down arrow does not overlaps the text.

[adhitya03]

I also try to look at the plugin's style and I found why this is happened. I think the main problem is the plugin's css padding select override wp-admin css padding select style.

in .wp-admin select

padding: 3px 24px 3px 8px

in table.sucom-settings td select.crop-area

padding: 2px;

and this is when we use padding from wp-admin.

[adhitya03]

And this is when we use default width from wp-admin select css

[adhitya03]

*sorry for bad English

[jsmoriss]

Replying to adhitya03:

And this is when we use default width from wp-admin select css

Yes, that is correct - changing the select padding value can move the arrow over the select option text, as shown in the example provided. When using the default select padding value from WP 5.3, then it works fine.

The question is really why use this background arrow image in the first place, which limits styling, when browsers already provide this same functionality.

js.

[iqbalbary]

Replying to jsmoriss:

The question is really why use this background arrow image in the first place, which limits styling, when browsers already provide this same functionality.

js.

I think, all browsers default style are not good enough and thats why the image is used.

[audrasjb]

Hi, and thanks for opening a Trac ticket!

The issues comes from custom CSS which is overriding default Admin CSS styles.

Plugins and theme authors shouldn't use custom (and fixed) width/height/padding/margin on form fields to allow them to automatically adapt themselves depending on the content of the field.

For further informations about Admin CSS changes in 5.3, see the related Make/Core Developer Note: ​https://make.wordpress.org/core/2019/10/18/noteworthy-admin-css-changes-in-wordpress-5-3/

[desrosj]

For reference, if anyone else trying to see the results in the screenshot, this is found in the ​following plugin when navigating to Settings > SSO Image Sizes.

I am going to close this one out as @audrasjb recommended. This is being caused by changes to the Core admin CSS that are meant to improve a11y in fields, so ideally plugins will make adjustments to accommodate and benefit from these changes. If there are more reports of this issue occurring in the wild, this can be reopened so that it can be investigated further.

That said, I did try to find an explanation for why <select> elements are now using a background image for the dropdown arrow but I could not find a definitive answer.

@audrasjb are you able to detail why this specific change was necessary to accomplish the goals of the accessibility tickets mentioned in that dev note?

[audrasjb]

Replying to desrosj:

That said, I did try to find an explanation for why <select> elements are now using a background image for the dropdown arrow but I could not find a definitive answer.

@audrasjb are you able to detail why this specific change was necessary to accomplish the goals of the accessibility tickets mentioned in that dev note?

It's simply how Gutenberg handle select element, @desrosj. That's why you cannot find any trace of this choice on Trac: we didn't took any decision on this specific implementation of this element on WP Core: it's Gutenberg’s territory.
Maybe it could be managed differently, but it's how the block editor handle it and it's fine from the accessibility side.

TL;DR: Not related to WP Core so if there is a problem with this implementation, it should be reported upstream on Gutenberg GitHub repository 😉

[afercia]

I agree wholeheartedly, and was surprised to see this in an accessibility change.

are you able to detail why this specific change was necessary to accomplish the goals of the accessibility tickets mentioned in that dev note?

I'm going to give the same answer :) Some visual changes came from the design team and they are design improvements implemented on top of the accessibility improvements. Worth noting Gutenberg already uses this specific style for <select> elements since several months. Consistency in the design across the admin is important and I guess we all agree to not have 2 different select styles in WordPress.

From an accessibility perspective, it really doesn't matter if a select uses native arrows or a custom arrow, as long as the control can be clearly identified as a select. Questions on similar visual changes should be asked to the design team. For what is worth I personally support these changes.

Regarding the WPSSO plugin, from what I see it uses custom CSS for the form controls. I do understand that many plugins have been forced for years to customize the styling of the core form controls because... let's face it: the core styles weren't great. Several inconsistencies in the default heights, paddings, etc., made alignments look far from ideal.

With the latest CSS changes, WordPress aims to improve this and for the future it means also less work for plugin authors. From the WordPress side, it's really not possible to predict what CSS properties plugins authors might use. Instead, what is possible is aiming to provide some decent, default styling.

Generally, as outlined in ​the Make post that details the admin CSS changes plugins should not use custom CSS for the form controls. I see WPSSO uses some custom CSS also for the inputs of type=text. With the new core styles, that's now not recommended and should be avoided.

Specifically plugin authors are invited to:

• remove any fixed height: flexible heights are now the WordPress recommended standard and one of the main accessibility goals as it allows form controls to better scale with text zoom
• remove any custom padding
• check if custom line-height values are used and if they have negative impact, remove them

[audrasjb]

Ah ah. What @afercia said, then :D