[wp-trac] [WordPress Trac] #48368: New select CSS in v5.3-RC1 overlaps text

[WordPress Trac]

#48368: New select CSS in v5.3-RC1 overlaps text
----------------------------+--------------------------------
 Reporter:  jsmoriss        |       Owner:  (none)
     Type:  defect (bug)    |      Status:  closed
 Priority:  normal          |   Milestone:
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:  wontfix
 Keywords:                  |     Focuses:  ui, accessibility
----------------------------+--------------------------------

Comment (by 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 woart, 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 [https://make.wordpress.org/core/2019/10/18
 /noteworthy-admin-css-changes-in-wordpress-5-3/ 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

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48368#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform