WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 5 weeks ago

Last modified 4 weeks ago

#47477 closed task (blessed) (fixed)

Content overflows and is cut off at 200% text enlarge

Reported by: kjellr Owned by: audrasjb
Milestone: 5.3 Priority: high
Severity: normal Version:
Component: Administration Keywords: needs-post-mortem has-screenshots wpcampus-report has-patch 5-3-admin-css-changes
Focuses: accessibility Cc:
PR Number:

Description (last modified by kjellr)

Moved from the WPCampus accessibility report issues on GitHub, see https://github.com/WordPress/gutenberg/issues/15356

Gutenberg inherits (and in some cases duplicates) some of the styles in question here, so I'm opening a Trac issue for this one as well. – @kjellr


Content overflows and is cut off at 200% text enlarge

  • Severity: Medium
  • Affected Populations:
    • Low-Vision
    • Cognitively Impaired
  • Platform(s):
    • All / Universal
  • Components affected:
    • Block Panel
    • Document Panel
    • (Also, buttons and form fields throughout WP-Admin)

Issue description

Several controls allow text to overflow out of them, or clip the text,
at 200% text enlarge. This is due to containers being set in fixed pixel
heights, which cannot grow with their content.

The checkmark icons move out of their checkboxes as they grow, leaving a
white checkmark against a white page background.

The ability to resize text is essential for users with low-vision, and
may be helpful for users who have a cognitive disability. Catering to
zoom alone is not sufficient because the browser's font-size may be
increased independently of zoom level.

Issue Code

/* selects */


    .wp-admin select {


        ...


        line-height: 28px;


        height: 28px;


        ...


    }





    /* checkboxes/radios */


    input[type=checkbox], input[type=radio] {


        ...


        height: 16px;


        ...


        width: 16px;


        min-width: 16px;    


    }





    /* buttons */


    .components-button.is-large {


        height: 30px;


        line-height: 28px;


        ...


    }





    .components-button.is-small {


        height: 24px;


        line-height: 22px;


        ...


        font-size: 11px;


    }





    /* pressable buttons */


    .components-toolbar__control.components-button {


        ...


        width: 36px;


        height: 36px;


    }





    /* number inputs */


    input[type=number] {


        height: 28px;


        line-height: 1;


    }

Remediation Guidance

Avoid setting fixed heights on elements (even inputs), and especially in
px units. Instead, set min-heights on containers, allowing them to
always expand to enclose their content, and allowing containers to
themselves wrap as needed.

The Recommended Code is using a minimum of 44px for the settings
(following https://www.w3.org/TR/WCAG21/#target-size), meaning
designers may want to reconsider how they want to show some buttons as
larger than others (visual importance), as well as dealing with
horizontal button rows wrapping as necessary (such as in the "Image
Resize" section of the Block Panel).

The checkboxes are made larger so that the growing checkmark icon
remains visible inside the checkboxes (by allowing them to grow with the
checkmark). These do not need to meet target size minimums as they are
inline with their (clickable) labels.

Recommended Code

 /* selects */


    .wp-admin select {


        ...


        min-height: 44px;


        ...


    }





    /* checkboxes/radios */


    input[type=checkbox], input[type=radio] {


        ...


        height: 1.5em;


        ...


        width: 1.5em;


        min-width: 16px;    


    }





    /* buttons */


    .components-button.is-large {


        min-height: 54px;


        ...


    }





    .components-button.is-small {


        min-height: 44px;


        ...


    }





    /* pressable buttons */


    .components-toolbar__control.components-button {


        ...


        min-width: 44px;


        min-height: 44px;


    }





    /* number inputs */


    input[type=number] {


        min-height: 44px;


    }

Relevant standards

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by [Tenon](https://www.tenon.io) and funded by [WP Campus](https://wpcampus.org/). This issue is GUT-32 in Tenon's report

Attachments (28)

tenon-screenshot.png (278.6 KB) - added by kjellr 6 months ago.
Screen Shot 2019-06-04 at 8.56.32 AM.png (70.8 KB) - added by kjellr 6 months ago.
Screen Shot 2019-06-04 at 8.55.41 AM.png (70.9 KB) - added by kjellr 6 months ago.
Screen Shot 2019-06-04 at 8.55.21 AM.png (58.6 KB) - added by kjellr 6 months ago.
47477.diff (3.5 KB) - added by kjellr 6 months ago.
47477.2.diff (2.4 KB) - added by kjellr 3 months ago.
47477.3.diff (3.8 KB) - added by kjellr 3 months ago.
47477.3-Darker-Borders.diff (3.7 KB) - added by kjellr 2 months ago.
47477.4-Darker-Borders.diff (4.1 KB) - added by kjellr 2 months ago.
47477.5.diff (2.9 KB) - added by talldanwp 8 weeks ago.
47477.6.diff (2.9 KB) - added by kjellr 8 weeks ago.
47477.4.diff (3.3 KB) - added by afercia 8 weeks ago.
input select different color.png (29.6 KB) - added by afercia 7 weeks ago.
47477.7.diff (15.5 KB) - added by afercia 7 weeks ago.
select in customiser.png (54.9 KB) - added by afercia 7 weeks ago.
47477.8.diff (18.4 KB) - added by afercia 7 weeks ago.
Screenshot (37).png (107.1 KB) - added by afercia 7 weeks ago.
Input fields and select elements in IE11 with latest trunk
47477.9.diff (2.8 KB) - added by afercia 7 weeks ago.
47477.10.diff (2.7 KB) - added by afercia 6 weeks ago.
47477 color picker.png (74.2 KB) - added by afercia 6 weeks ago.
The color picker looks good to me both in the Customizer and in the legacy Custom Background page:
47477 inputs comparison windows mac.png (90.6 KB) - added by afercia 6 weeks ago.
47477 buttons comparison windows.png (11.3 KB) - added by afercia 6 weeks ago.
media-modal-menus.png (8.1 KB) - added by azaozz 6 weeks ago.
47477.11.diff (10.2 KB) - added by afercia 5 weeks ago.
47477 wp-style-guide.png (104.7 KB) - added by afercia 5 weeks ago.
Examples of buttons, link styled as buttons, and alignments using a modified version of the wp-style-guide plugin by Helen.
select-in-5.3.jpg (116.6 KB) - added by joyously 5 weeks ago.
This is 5.3 RC1 in two browsers. Top is SeaMonkey, bottom is Firefox. (Ubuntu)
select-on-firefox.jpg (15.9 KB) - added by joyously 5 weeks ago.
The Dev Tools in Firefox shows -moz-appearance: none. This isn't shown in SeaMonkey.
Screen Shot 2019-11-02 at 9.27.42 PM.png (48.0 KB) - added by johnjamesjacoby 2 weeks ago.
Weird border color inconsistencies with classic editor

Download all attachments as: .zip

Change History (104)

@kjellr
6 months ago

#1 @kjellr
6 months ago

I've included the original Gutenberg screenshot from the report, as well as a couple other examples inside of WP-Admin, which are more relevant to this specific ticket.

The WP-Admin screenshots were created with Firefox's Text Zoom option (set to 200%). @afercia notes that this is not exactly the same thing as the text zoom settings noted above, but it gives a general idea of the issue. (reference)


47477.diff includes a quick pass at the updates here. It's a start, but is definitely not ready to land. Some notes:

  • In general, it aims to remove imposed heights for buttons, select fields, and number fields, in favor of min-height. This helps make sure these elements don't break when text is zoomed, but it's likely to cause some visual bugs as well.
  • For instance: min-height for select fields appears to be ignored in Safari. Which isn't great.
  • This patch also includes a quick fix for the checkboxes issue — It replaces the icon-font based checkmark with an SVG one which won't scale up and break. While switching to a SVG seems like a reasonable solution here (to me at least), this implementation could certainly be improved.

With the patch applied, here are the updated screenshots:

https://cldup.com/iL0n4Z9Pyt-3000x3000.png

https://cldup.com/rPnvS54rX1-3000x3000.png

https://cldup.com/BLhjFxyBTv-3000x3000.png

#2 @kjellr
6 months ago

  • Description modified (diff)

#3 @kjellr
6 months ago

  • Summary changed from Open Content overflows and is cut off at 200% text enlarge to Content overflows and is cut off at 200% text enlarge

#4 @SergeyBiryukov
6 months ago

  • Component changed from General to Administration

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


5 months ago

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


3 months ago

@kjellr
3 months ago

#7 @kjellr
3 months ago

I've updated the patch to remove the checkbox implementation, since that's being handled separately in #47498.

New patch: 47477.2.diff


The main issue I see with the patch currently is that it introduces a regression in the size/alignment of the select fields when viewed without text zoom. For example:

Chrome @ 100%, today:

https://cldup.com/9_nsd4vN6X.png

Chrome @ 100%, with this patch:

https://cldup.com/NQORXIrmxV.png

From some quick research, it doesn't appear that Webkit will respect min-height values on Select fields at all — only height. 😞

(Chrome also seems to remove the box shadows for those filter buttons for some reason, though I expect that's unrelated).


The select fields aren't only problematic in Webkit though: They also don't look right in Firefox:

Firefox @ 100%, today:

https://cldup.com/2sVQw2AV01.png

Firefox @ 100%, with this patch:

https://cldup.com/M26gWoDKbQ.png


Last edited 3 months ago by kjellr (previous) (diff)

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


3 months ago

#9 @joedolson
3 months ago

  • Owner set to abrightclearweb
  • Status changed from new to assigned

@kjellr
3 months ago

#10 @abrightclearweb
3 months ago

I'm trying to test your patches @kjellr but I'm getting errors.

forms.css has 5 failed hunks and buttons.css has 7 failed hunks.

If I try to apply the patches anyway, an src folder is created in my WordPress folder that adds the code, but I don't think that's where I want it, because the paths are wrong.

Can you suggest a fix?

#11 @kjellr
3 months ago

I spent some time looking into that select field issue this morning, and it seems like the only way around this would be to use -webkit-appearance: none and add a custom dropdown arrow. I've attached 47477.3.diff, which tries this approach.

This looks consistent in all browsers, and mimics the style of our buttons:

https://cldup.com/qmTYfO-oBe.png

It works well with text zoom. Here's an example at 300%:

https://cldup.com/s6ndRCxmwF.png

I was encountering an issue where our max-width rules for table header select fields were cutting text off horizontally in those fields. Converting those max-widths to rem units instead seemed to solve that, so this patch includes that fix as well.

Note that with this approach, we'll need to sync up any changes here with button updates in #34904. Since this latest update changes the design of the select form fields, I'll add needs design feedback for a gut check from other designers.

Last edited 3 months ago by kjellr (previous) (diff)

#12 @kjellr
3 months ago

If I try to apply the patches anyway, an src folder is created in my WordPress folder that adds the code, but I don't think that's where I want it, because the paths are wrong.

@abrightclearweb Thanks for trying to test. Are you running the version of WordPress that's located in the develop repository? If so, you should have a /src/ directory already:

https://make.wordpress.org/core/handbook/testing/patch/

#13 @kjellr
3 months ago

  • Keywords needs-design-feedback added

#14 @abrightclearweb
3 months ago

@kjellr I'm not sure. I have WordPress 5.3-alpha-45933.

I'm trying not to use the command line for testing, it seems to break if I so much as look at it.

Unfortunately there's no content in the Testing Without Grunt section in the [Testing a Patch]https://make.wordpress.org/core/handbook/testing/patch/ doc. :(

I set up a site on DesktopServer using the [Blank (WordPress SVN) method]https://make.wordpress.org/core/handbook/tutorials/installing-a-local-server/desktopserver/#3-configuring-desktopserver.

Then I installed TortoiseSVN and added WordPress [via this method]https://make.wordpress.org/core/handbook/tutorials/installing-wordpress-locally/from-svn/#1-check-out-wordpress-trunk

I had a go at creating my own patch and reverting it. I've applied a few others with success e.g. (https://core.trac.wordpress.org/ticket/47019#comment:10) but I can't get yours to work.

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


3 months ago

#16 @kjellr
2 months ago

I've just uploaded a new patch that updates the custom select button styles to reflect the button changes proposed in https://core.trac.wordpress.org/ticket/34904#comment:47

If that patch is committed, we should use 47477.3-Darker-Borders.diff for this ticket. That patch will make sure the form fields match the new buttons.

Buttons in 47477.3.diff:

https://cldup.com/z8E-K7WtwT-3000x3000.png

Buttons in 47477.3-Darker-Borders.diff:

https://cldup.com/mjf7jnjjbW-3000x3000.png

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


2 months ago

#18 @audrasjb
2 months ago

  • Keywords has-patch commit added; needs-design-feedback removed

I tested 47477.3-Darker-Borders.diff and it's looking good to me.

Worth reminding it should be committed alongside with #34904.

#19 @audrasjb
2 months ago

  • Owner changed from abrightclearweb to audrasjb
  • Status changed from assigned to accepted

#20 @kjellr
2 months ago

Added a tiny update in 47477.4-Darker-Borders.diff — I noticed the media selects were broken in the last update. This takes those into account as well.

Before
https://cldup.com/4-LiGO7wgk-3000x3000.png

After
https://cldup.com/yHO_j-jtnb-3000x3000.png

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


8 weeks ago

#22 @afercia
8 weeks ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 46243:

Accessibility: Improve and modernize user interface controls. Third part: allow buttons and form controls to scale with text.

Props kjellr, abrightclearweb, audrasjb.
Fixes #47477.

#23 @afercia
8 weeks ago

  • Keywords commit removed

#24 @kjellr
8 weeks ago

Taking note of some some visual bugs related to the latest patch that @desrosj shared on Slack:
https://wordpress.slack.com/archives/C02RP4X03/p1569257093484500

I am on MacOS using the Firefox nightly edition. However, I was able to reproduce these issues on the latest regular, public release version.

We'll get those sorted out in a new patch. 👍

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


8 weeks ago

#26 @afercia
8 weeks ago

Related: #48129: the select elements disabled state needs to be styled.

@talldanwp
8 weeks ago

#27 follow-up: @talldanwp
8 weeks ago

I've uploaded 47477.5.diff which fixes some of the issues mentioned on #47153.

  • Fixes to margin of select elements to ensure text is centered
  • Fixes to quick edit form
  • Removal of native down arrow on select elements in IE

#28 @talldanwp
8 weeks ago

As a general comment it's pretty unusual that the font size for form elements is 14px, while buttons are 13px. That seems to be the main thing that makes it all look slightly wrong.

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


8 weeks ago

#30 @audrasjb
8 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Type changed from defect (bug) to task (blessed)

Reopening this ticket as a blessed task to allow us to iterate on the related changes.

Reopened tickets: #47153, #47477, #47498, #48101

@kjellr
8 weeks ago

#31 in reply to: ↑ 27 @kjellr
8 weeks ago

I've uploaded 47477.5.diff which fixes some of the issues mentioned on #47153.

  • Fixes to margin of select elements to ensure text is centered
  • Fixes to quick edit form
  • Removal of native down arrow on select elements in IE

Thanks, @talldanwp! These look great. When testing in FF for Mac, the text wasn't quite centered for me, so I added a line-height rule in 47477.6.diff which fixed it:

https://cldup.com/pTpxBK94CB-2000x2000.png

As a general comment it's pretty unusual that the font size for form elements is 14px, while buttons are 13px. That seems to be the main thing that makes it all look slightly wrong.

That's a great observation. 😄 I've also changed the font size to 13px in my patch. Since these are specifically based on the button styles, I think that's a fair change to make here.

@afercia
8 weeks ago

#32 @afercia
8 weeks ago

Note: when uploading patches it's best to not manually rename a patch file which contains a version "dot + number" e.g. nnnnn.4.something-else otherwise the automatic progressive numbering handled by Trac breaks :)

47477.4.diff is the latest patch so far. I built on previous patches and was able to reset the Firefox focusring.

Still to do: improve the left and right paddings: they look different on Chrome and Firefox. Would be great to have a look at the examples mentioned on #47153 that have a good cross-browser padding. I'd think we should be able to get the same result. Here's the examples:

Scott O'Hara Styled Selects
https://scottaohara.github.io/a11y_styled_form_controls/src/select/
https://github.com/scottaohara/a11y_styled_form_controls/blob/master/src/assets/css/select.css

Yoast styled select
https://github.com/Yoast/wordpress-seo/blob/304116593abb8a06f74b9c8ae20f55ec8c689ba8/css/src/yst_plugin_tools.scss#L773

both inspired by:
Scott Jehl
Styling a Select Like It’s 2019
https://www.filamentgroup.com/lab/select-css.html

Also still to address: #48129 and to evaluate: #48128.

This ticket was mentioned in Slack in #design by kjell. View the logs.


8 weeks ago

#34 @afercia
7 weeks ago

  • Keywords 5-3-admin-css-changes added

#35 @afercia
7 weeks ago

In 46337:

Accessibility: Improve and modernize user interface controls. Make the select elements background white.

Props adhitya03.
See #47477.
Fixes #48128.

#36 @afercia
7 weeks ago

In 46339:

Accessibility: Improve and modernize user interface controls. Style the select elements disabled state.

Props adhitya03, MarcosAlexandre, kjellr.
See #47477.
Fixes #48129.

#37 @afercia
7 weeks ago

In 46340:

Accessibility: After [46337]: make the select elements background white also on hover, active, and focus states.

See #47477.
See #48128.

#38 @afercia
7 weeks ago

Still to do: improve the left and right paddings: t

I dove a bit into this and I'm not sure I'm able to make the left / right paddings look the same on webkit and gecko. Seems to me this small difference is visible also on the examples mentioned above.

There's some small extra padding in Firefox that appears to come from some internal Firefox rendering. Will commit last patch because it is an improvement. Padding can be always iterated later if a solution gets identified.

Last edited 7 weeks ago by afercia (previous) (diff)

#39 @afercia
7 weeks ago

Noticed the new select has a different text color compared to the input fields color. This may make sense but when these two elements are placed close each other, not sure the different colors look great. Will definitely leave this to the design team :) /Cc @kjellr

See attached screenshot (note: the different height is a known and pre-existing issue, please ignore).

@afercia
7 weeks ago

#40 @afercia
7 weeks ago

47477.7.diff is a pretty large patch that seeks to address most of the remaining issues related to sizes.

There are certainly other cases still to address but I'd suggest to test this patch. It should make further improvements easier. Things to test:

  • all the main admin screens form controls and buttons
  • the media library and the various media modal views
  • the customizer
  • multisite! @johnjamesjacoby :)
  • Gutenberg? :)
  • all the above in the responsive views
  • anything else

Please note there are some elements that have slightly different heights. This is a pre-existing issue and would need some decisions on new, better, values for the small / normal / large sizes of various elements. It's a bit out of the scope of this ticket though, as the main goal here is to allow elements to scale with text zoom so that they don't cut off important content.

I'd tend to think the best option now would be to catch and fix the remaining cases and plan further major improvements for the future.

Last edited 7 weeks ago by afercia (previous) (diff)

#41 @johnjamesjacoby
7 weeks ago

multisite! @johnjamesjacoby :)

I've quickly & manually reviewed the Multisite Network admin-area pages, and things look OK to me. The only Network-Admin issues are similar to Site-Admin Bulk Actions, where the Select element is taller than the "Apply" button, which was noted and attached on #47153.

#42 @kjellr
7 weeks ago

Noticed the new select has a different text color compared to the input fields color. This may make sense but when these two elements are placed close each other, not sure the different colors look great. Will definitely leave this to the design team :) /Cc @kjellr

Good catch, @afercia. I think we should use the same text color as the input fields here. 👍

#43 @afercia
7 weeks ago

Thanks @kjellr! Also, the .wp-admin select color "wins" on the Gutenberg select color that is supposed to be #555d66. At least on current trunk :)

#44 @afercia
7 weeks ago

Worth noting in the Customizer the select elements have the old style. There's no wp-admin class in the Customiser. See screenshot below (menus locations in the Customizer).

This ticket was mentioned in Slack in #core-editor by afercia. View the logs.


7 weeks ago

@afercia
7 weeks ago

#46 @afercia
7 weeks ago

47477.8.diff addresses most of the reported cases that need adjustments.

It mainly relates to select elements and input fields heights on both desktop and mobile. Also search forms heights and styling, now more standardized.

What this patch does not addresses:

For Gutenberg, this patch needs to be accompanied by a tiny change, see https://github.com/WordPress/gutenberg/pull/17659

Testing is greatly appreciated. Please test on both Chrome and Firefox.

I’d kindly ask everyone to please compare with previous versions before reporting glitches or regressions: as said, several issues aren't regressions and already happen in WordPress 5.2 and previous versions.

#47 @afercia
7 weeks ago

In 46356:

Accessibility: Improve and modernize user interface controls: Improve the new form controls styles and heights.

Improves cross-browsers rendering and addresses most of the reported edge cases.

See #47477.

#48 @afercia
7 weeks ago

In 46362:

Media: Fix the media modal "Insert from URL" field height after [46356].

See #47477.

#49 @afercia
7 weeks ago

For Internet Explorer 11, there's the need to set an explicit min-height value to all the input fields because in IE11 line-height has no effect. Select elements look okay. See screenshot below.

@afercia
7 weeks ago

Input fields and select elements in IE11 with latest trunk

#50 @afercia
7 weeks ago

The customizer input fields need a quick fix. Reported by @desrosj and @garret-eclipse on #47153. Patch by @garret-eclipse: https://core.trac.wordpress.org/attachment/ticket/47153/47366.customizer.lineheight.diff

@afercia
7 weeks ago

#51 @afercia
7 weeks ago

For what is worth, I uploaded a last patch to address all the pending cases I was able to find.

47477.9.diff improves:

  • input fields height in the customizer: reported and patched by @garret-eclipse on #47153
  • input fields height with Internet Explorer 11
  • input fields height in the Image Editor
  • alignment of select and button in the privacy policy pages

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


7 weeks ago

#53 @audrasjb
7 weeks ago

Patches looks good on my side! Thanks Andrea 😎

This ticket was mentioned in Slack in #core by ocean90. View the logs.


6 weeks ago

#56 @joedolson
6 weeks ago

Note: not intended to imply that the patch caused the error; just that it's an additional misalignment not covered by the patch.

@afercia
6 weeks ago

#57 @afercia
6 weeks ago

47477.10.diff refreshes and cleans-up 47477.9.diff.

#58 @afercia
6 weeks ago

In 46419:

Accessibility: Improve and modernize user interface controls for better contrast: Further improvements to input heights and alignments.

  • improves input fields height in the customizer
  • improves input fields height for Internet Explorer 11
  • improves input fields height in the Image Editor
  • improves alignment of selects and buttons in the privacy policy pages
  • makes the search themes fields font-size consistent

Props garrett-eclipse, afercia.
See #47477.

@afercia
6 weeks ago

The color picker looks good to me both in the Customizer and in the legacy Custom Background page:

#59 @azaozz
6 weeks ago

  • Priority changed from normal to highest omg bbq
  • Severity changed from normal to major

Looking at all the changes here again, why all the last minute padding changes? They break all the (old style) structural CSS tweaks in so many places and make it all look pretty bad.

Also some other inconsistent things like font-size for select is reduced? Why? How does this make it better :)

Frankly I'm thinking we should revert all padding and other "non-essential" changes and only fix whatever is broken, i.e. fulfil the original purpose of this ticket. That'd mean only convert hard pixel values in rem or other "soft" units.

#60 @afercia
6 weeks ago

@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 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.

#61 @afercia
6 weeks ago

In the screenshots below:

Input fields: No vertical alignment relevant difference on Windows. The difference with macOS is because of system fonts.

  • WordPress 5.2 on Windows Chrome
  • WordPress trunk on Windows Chrome
  • WordPress trunk on macOS Chrome

Buttons: No vertical alignment relevant difference on Windows.

  • WordPress 5.2 on Windows Chrome
  • WordPress trunk on Windows Chrome

#62 @azaozz
6 weeks ago

@afercia These aren't "huge" regressions but nevertheless make a lot of places in wp-admin look worse than before. For the above example:

  • Vertically slightly off-center.
  • Arrows off-center.
  • Height is different/doesn't match.
  • Font-weight is different/doesn't match.
  • Width different (will affect translated strings).

None of these is a big problem by itself, and given enough time, this could have been refined/done much better. The main problem is we are out of time, so now the choice is either to keep it looking bad/inconsistent or revert it :(

Last edited 6 weeks ago by azaozz (previous) (diff)

#63 @azaozz
6 weeks ago

  • Keywords needs-post-mortem added

#64 @audrasjb
6 weeks ago

  • Priority changed from highest omg bbq to high
  • Severity changed from major to normal

Hello @azaozz @afercia,

Thanks for sharing thoughts and screenshots about this issue, it's a great to help to understand it.
Given the screenshot shared, I don't think the issue objectively deserves the highest priority in Trac, and a major severity.
Resetting them to "high" and "normal" so it's not overestimated within track reports (other ticket may need high priority like the jQuery one) :-)

@azaozz for perfect understanding of the issue, could you please share the context of your screenshot, to help to reproduce it? Thank you very much!

#65 @afercia
6 weeks ago

@azaozz thanks for clarifying.

The main problem is we are out of time

The first set of changes on this ticket was committed on 09/23/2019 04:26:24 PM (see comment 22) which, technically, is before Beta 1 :) Just to clarify a process detail. Please allow me to say that maybe feedback from other teams came a bit out of time.

Regarding your points, referring to the screenshot you posted:

http://cldup.com/wUheyxjVub.png

Vertically slightly off-center.
I see it and I know. But please look at the previous inconsistencies, which are way worse. I wouldn't say the previous select and inputs are nicely aligned: these inconsistencies are all over the place in WordPress 5.2 and all previous versions as there's really no standard height for the form controls. Instead, I'd say the current style is an improvement. Anyways, I commented previously on https://core.trac.wordpress.org/ticket/34904#comment:109 that this just needs a decision. Given the CSS is now way simpler, we can easily standardize the default height of all controls: inputs, selects, buttons to 28px or 30px. Just needs a decision. I haven't got any constructive feedback yet, though.

Also, as I previously commented, there are design plans for the future to use a "standard grid" probably based on 8 pixels and it's very likely all form controls will have an even bigger height: 32 pixels on desktop for the normal size and 40 pixels on mobile.

Also, as I said previously, the text alignment on Windows is a "system fonts" issue. The only way to solve it reliably is to change the font stack removing "Segoe UI". Please notice this text alignment issue on Windows is clearly visible on WordPress 5.2 and all previous versions.

Arrows off-center.
Honestly, I don't see the arrows are off-center.

Height is different/doesn't match.
See above: just needs a decision and, regardless, this is a pre-existing issue clearly visible all over the place on WordPress 5.2 and all previous versions.

Font-weight is different/doesn't match.
Not sure I follow. Maybe the different font weight of "Filter Media" and "Search"? The former is a heading, the latter is a <label> element so they have a native different weight. Not sure this is a serious breakage :) Not a regression, as these are new in 5.3.

Width different (will affect translated strings).
Not sure I follow. The selects maybe? Their width is determined by the longest <option> element within them so they will adjust their width with longer translations. Regardless, all the "float-drops" and breakages that happen in WordPress 5.2 and all previous versions will still happen in 5.3. On this regard, I think we agree the toolbar CSS is far from ideal and would need a substantial refactoring. This issue exists since... forever.

In all honesty, I don't see how all this can justify a revert. If there are other serious reasons to consider a revert, I'd be happy to be informed to better consider the best path forward.

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


6 weeks ago

@afercia
5 weeks ago

#67 @afercia
5 weeks ago

During the latest shared meeting between the design team and the accessibility team on Slack (requires registration) it was agreed to standardize the height of inputs, selects, and buttons to 30 pixels.

47477.11.diff does that and adjusts the other button sizes to keep the same scale ratio. With this change, form controls are better aligned and various exceptions are no longer necessary.

Some testing would be nice :)

@afercia
5 weeks ago

Examples of buttons, link styled as buttons, and alignments using a modified version of the wp-style-guide plugin by Helen.

#68 @audrasjb
5 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

@afercia let's handle those changes in further release, since we are going to have a RC1 today.
I think it could clearly land in a quick 5.3.1 release :-)
Closing the ticket as fixed for now.

This ticket was mentioned in Slack in #core by afercia. View the logs.


5 weeks ago

#70 @afercia
5 weeks ago

Sure. To better illustrate, 47477.11.diff would also solve these kind of alignments. Worth noting some of them (second screenshot in these examples) always existed in core and historically forced plugins to use custom CSS to adjust the input heights:

http://cldup.com/2Dv4xEhDxu.png

http://cldup.com/DlUS90v-aI.png

http://cldup.com/nzKiYmORv9.png

Last edited 5 weeks ago by afercia (previous) (diff)

#71 @afercia
5 weeks ago

To further clarify:

This is the alignment of default input fields and buttons in WordPress 5.2: the elements are already misaligned (and this can be reproduced on all previous versions):

http://cldup.com/MhW29WJO8i.png

And this is the current alignment in WordPress 5.3 trunk:

http://cldup.com/wU5BQR0kvV.png

47477.11.diff would solve this issue by making all form controls default height 30 pixels.

Last edited 5 weeks ago by afercia (previous) (diff)

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


5 weeks ago

@joyously
5 weeks ago

This is 5.3 RC1 in two browsers. Top is SeaMonkey, bottom is Firefox. (Ubuntu)

@joyously
5 weeks ago

The Dev Tools in Firefox shows -moz-appearance: none. This isn't shown in SeaMonkey.

#73 @joyously
5 weeks ago

While I'm aware that SeaMonkey isn't a supported browser, if the -moz prefix was used, it would work in all Mozilla browsers. (Apparently, recent Firefox changes the -webkit prefix to -moz internally.)

#74 @afercia
5 weeks ago

As explored on Slack (requires registration) looks like adding the -moz-appearance prefixed version would address the SeaMonkey issue and likely old Firefox versions issues. Though these browsers aren't officially supported, I don't see any harm in adding better coverage with the -moz- prefixed version. Adding the unprefixed one would be nice too.

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


5 weeks ago

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


4 weeks ago

@johnjamesjacoby
2 weeks ago

Weird border color inconsistencies with classic editor

Note: See TracTickets for help on using tickets.