[wp-trac] [WordPress Trac] #47477: Content overflows and is cut off at 200% text enlarge

[WordPress Trac]

#47477: Content overflows and is cut off at 200% text enlarge
-------------------------------------------------+-------------------------
 Reporter:  kjellr                               |       Owner:  audrasjb
     Type:  task (blessed)                       |      Status:  reopened
 Priority:  highest omg bbq                      |   Milestone:  5.3
Component:  Administration                       |     Version:
 Severity:  major                                |  Resolution:
 Keywords:  has-screenshots wpcampus-report      |     Focuses:
  has-patch 5-3-admin-css-changes                |  accessibility
-------------------------------------------------+-------------------------

Comment (by afercia):

 @azaozz thanks for sharing your concerns.

 > why all the last minute padding changes?
 A first set of changes to padding was implemented in [46356] on
 09/30/2019. That's 10 days ago. I wouldn't call that "last minute" changes
 :) That change improved input fields height consistency across the admin
 and in the responsive view.

 A ''second'' set was implemented in [46419] 3 days ago. That's necessary
 for IE 11 (see [attachment:"Screenshot (37).png"]  ) because line-height
 doesn't have any effect on IE11.

 In most of the cases input fields now use a 0 pixels top and bottom
 padding. The height is determined by:
 - unitless line-height: this allows input fields to scale with text zoom
 - min-height: necessary for IE11


 > They break all the (old style) structural CSS tweaks in so many places
 and make it all look pretty bad.

 Could you please provide specific examples of breakages that happens in
 "so many places"? I don't want to sound unfair but calling for a revert
 without providing specific cases of serious regressions / breakages isn't
 that helpful.
 Personally, I couldn't find serious breakages or things that "look pretty
 bad". Any better detailed feedback is very welcome and would allow to fix
 potential edge cases.

 I know you're on Windows. If you're referring to text not perfectly
 vertically centered within input fields, please notice that it happens
 also on WordPress 5.2. It doesn't have anything to do with these changes.
 It happens since the change to "system fonts" and because "Segoe UI" (the
 default font used on Windows) has an uneven half-leading internal metrics.
 That is: it's not vertically centered within the line-height. If we want
 to improve this, the only option is to change the font stack and make
 Windows use another font e.g. Arial.

 > structural CSS tweaks
 Ideally, there shouldn't be "tweaks" or too many variants of the input
 fields. Specifically, the height shouldn't change too much. In the past,
 there were some cases of very small input fields that were hard to use for
 many users. Some input fields are now bigger. That's intentional.
 Standardizing most of the input fields to have the same height is a
 valuable change in my opinion. Not to mention CSS simplification and
 easier maintenance.

 Please also notice that starting from
 https://core.trac.wordpress.org/ticket/34904#comment:94 an interesting
 conversation with design started around the introduction of a "standard
 grid" probably based on 8 pixels. I foresee a future for all form controls
 where they will have an even bigger height: 32 pixels on desktop for the
 normal size and 40 pixels on mobile.

 Worth also noting that most of the visual changes added by design on top
 of the accessibility changes aim to introduce consistency between the
 Gutenberg styles and the admin styles. Gutenberg is out since almost one
 year now. However, there are still two complete different form controls
 styles in WordPress: the Gutenberg ones and the legacy admin ones. Sooner
 or later they need to be standardized, as there's no value in forcing
 users to "learn" two different visual patterns.
 These changes were discussed publicly and agreed by the design team.

 Lastly, a quick consideration about process: I would have appreciated some
 help in implementing all these changes. Feedback from everyone is always
 welcome. Positive, constructive, feedback is better.

 I'm not sure there's any need to raise this ticket priority to "highest
 omg bbq". This ticket is a task: it's meant to stay open for all the Beta
 and Release Candidate period. I'd greatly appreciate positive, specific,
 feedback and help on the edge cases that need to be fixed (if any) instead
 of fear for a change that, as said above, needs to happen anyways sooner
 or later.

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