WordPress.org

Make WordPress Core

Opened 6 months ago

Closed 2 months ago

Last modified 8 weeks ago

#47498 closed task (blessed) (fixed)

Revise checkbox/radio button css for better compatibility with text zoom

Reported by: kjellr Owned by: audrasjb
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Administration Keywords: wpcampus-report form-controls color-contrast 5-3-admin-css-changes has-patch has-dev-note
Focuses: ui, accessibility Cc:
PR Number:

Description

Related to #47477. This just breaks out one smaller, manageable piece of the patch for review.


The current implementation of checkboxes in WP-Admin relies on using the Dashicons icon font to render the checkbox. When a user uses a text zoom feature in their browser, this icon is scaled up and misplaced:

200% Text Zoom:
https://cldup.com/0LPkuLI8pX-2000x2000.png

The scaling up does not happen for radio buttons because those rely on pixel sizes and CSS to render the dot at the center of the circle. The radio buttons do call for a bullet symbol from the Dashicons font, but move it out of view using a negative text indent.

To prevent the checkbox issue and clean up our checkbox/radio buttons styles in general, I suggest we take one of two actions:

  1. Switch to SVGs instead of the Dashicons webfont. These won't scale up disproportionally with text zoom, and are altogether a more modern approach. We can use a SVG of the "Yes" Dashicon for the checkmark, but there's no plain circle in Dashicons to use for the radio button. We could either create a circle SVG, or just leave the radio button dot as is, since it's already rendering a circle using CSS and doesn't actually need Dashicons at all to accomplish what it's doing.
  1. Render both the dots and checkmarks using only CSS. The dots are easy: as noted above, they're actually rendering with just CSS today. Checkmarks are a little more complicated, but still not entirely difficult. The downside here is that it won't look exactly like the Dashicon check. Here's a quick example: https://codepen.io/kjellr/pen/NVVNzE

I'm attaching a patch that follows (one variation of) the 1st approach:

  • It uses an SVG instead of the Dashicons webfont for the checkbox checkmark. Since this is used as a pseudo element, the SVG has to be called as an external file, though we could use a data URL if we want to save the browser an extra request.
  • It removes the reliance on the Dashicons webfont for radio buttons. As far as I can tell, this isn't actually used anywhere, since the circle icon is created purely via CSS.

The patch should produce no visible difference when viewed at 100%, but it'll fix the checkbox issue when text zoom is active.

200% Text Zoom:
https://cldup.com/Y9lqcVv2Cx-3000x3000.png

Attachments (13)

47498.diff (1.5 KB) - added by kjellr 6 months ago.
47498-alternate.diff (1.3 KB) - added by kjellr 5 months ago.
47498-url-encoded.diff (2.5 KB) - added by afercia 5 months ago.
radio checkboxes dont scale.png (137.5 KB) - added by afercia 4 months ago.
47498.2.diff (3.2 KB) - added by kjellr 4 months ago.
47498.3.diff (3.7 KB) - added by kjellr 4 months ago.
47498.4.diff (3.9 KB) - added by kjellr 3 months ago.
47498.5.diff (3.9 KB) - added by afercia 3 months ago.
gutenberg checkboxes.png (96.3 KB) - added by afercia 3 months ago.
Discussion Settings.png (49.0 KB) - added by desrosj 3 months ago.
General Settings.png (66.6 KB) - added by desrosj 3 months ago.
Props @garrett-eclipse
47498.6.diff (481 bytes) - added by afercia 3 months ago.
checkbox color schemes.png (122.5 KB) - added by afercia 2 months ago.
Checkbox with the Midnight color scheme.

Download all attachments as: .zip

Change History (55)

@kjellr
6 months ago

#1 @afercia
6 months ago

  • Keywords needs-design-feedback added

#2 @afercia
6 months ago

Note about the current CSS used for the radio buttons: \2022 is not a glyph in the dashicons font, it's just the "bullet" unicode character. It appears the related CSS rule in forms.css has always been incorrect.
See https://core.trac.wordpress.org/ticket/47183#comment:2

#3 @afercia
6 months ago

  • Keywords wpcampus-report added

#4 @afercia
6 months ago

  • Keywords form-controls color-contrast added

Previously:

Redesign input fields, checkboxes and other form components for contrast and consistency
https://core.trac.wordpress.org/ticket/44749

Stop using dashicons to show checked state of checkboxes
https://core.trac.wordpress.org/ticket/38150

Color contrast: checkboxes and radio buttons
https://core.trac.wordpress.org/ticket/35596

#5 @afercia
6 months ago

  • Milestone changed from Awaiting Review to 5.3

Moving to the 5.3 milestone, as this ticket aims to address one of the issues from the WPCampus accessibility report on Gutenberg and all the other related tickets are already set to 5.3.

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


6 months ago

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


5 months ago

#8 @kjellr
5 months ago

Thanks for the background, @afercia.

---

I'm including a second version of the patch that includes the SVG inline, to avoid another browser request. The two patches are:

47498.diff: Uses CSS to draw the bullet in radio buttons, calls a SVG for the checkmark in checkboxes.

47498-alternate.diff: Uses CSS to draw the bullet in radio buttons, uses an inline SVG in the CSS for the checkmark in checkboxes.

Both remove the dependency on Dashicons. I don't have a strong preference for either approach, so happy to hear thoughts from other folks.

Thanks!

#9 @afercia
5 months ago

Thanks @kjellr! Tested a bit and:

  • 47498.diff misses a dot in the image URL path, it should be ../
  • 47498-alternate.diff works only in Safari for me:
    • I'm not sure the <rect> element in the SVG is necessary, unless I'm missing something
    • regardless, turns out the checkmark fill value contains the hash character fill='#1e8cbe' and changing that to, for example, fill='red' makes the icon work in all browsers (also IE11).

Solution: URL encode the part that starts with <svg ... > and ends with </svg>, as also suggested here.

That said, both the checkbox checkmark and the radio button "circle" are supposed to change color when an admin alternate color scheme is set. For example, with the "Midnight" color scheme, they should be red:

http://cldup.com/KeLgQcdXYN.png

The fill color should be set dynamically in src/wp-admin/css/colors/_admin.scss but then again the color variable will output a hash character #. There's the need for some Sass to handle this special case.

47498-url-encoded.diff is a proof of concept (it works), if anyone comes up with a better method to replace the hash character # with the URL-encoded value %23, that would be welcomed!

Some testing would be nice :)

#10 @kjellr
5 months ago

Excellent improvement, @afercia. Thanks for sorting out the URL encoding. It makes the code a lot less readable, but at least it works this time around. I can confirm that this fixes the color for various color schemes as well. 👍

if anyone comes up with a better method to replace the hash character # with the URL-encoded value %23, that would be welcomed!

I can't think of one offhand  — trimming that off the string like you're doing seems okay. I do think it's worth adding an inline comment above that function to explain what it's for.

Thanks again!

#11 @karmatosed
5 months ago

  • Keywords needs-design-feedback removed

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


4 months ago

#13 @audrasjb
4 months ago

  • Owner set to audrasjb
  • Status changed from new to reviewing

#14 @afercia
4 months ago

Looking at this after some time. While the current patch fixes the position of the checkmark, radio buttons and checkboxes still don't scale with text zoom (see screenshot attached below).

Re-defining all the metrics using em (or rem) like in this technique from Adrian Roselli, would allow these controls to scale together with text when zooming only text (e.g. with Firefox) or when increasing the default font size from the operating system settings. Is there already a ticket for this?

@kjellr
4 months ago

#15 @kjellr
4 months ago

Looking at this after some time. While the current patch fixes the position of the checkmark, radio buttons and checkboxes still don't scale with text zoom (see screenshot attached below).

Re-defining all the metrics using em (or rem) like in this technique from Adrian Roselli, would allow these controls to scale together with text when zooming only text (e.g. with Firefox) or when increasing the default font size from the operating system settings. Is there already a ticket for this?

I don't think there's another ticket for it. Changing this is relatively trivial though. I've updated the patch to use em instead of px. Here's how that same screen looks with 47498.2.diff applied:

http://cldup.com/muwThI6oEt.png

Last edited 4 months ago by afercia (previous) (diff)

#16 @afercia
4 months ago

Cool, thanks @kjellr!

I've updated the patch to use em

What happens now when radios and checkboxes are used in a page where the font size is different? Will they have a different size as well? If that's the case, wouldn't be better to use rem?

@kjellr
4 months ago

#17 @kjellr
4 months ago

If that's the case, wouldn't be better to use rem?

Yeah, good call. I've added 47498.3.diff, which makes that change. It also changes the small-screen values to rem, which I missed the first time around.

One small note:

There's still a padding rule that uses px, but I think it's actually totally unused?
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/css/forms.css#L1264

It appears to be overridden by the !important above:
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/css/forms.css#L83

If that's truly unused, I'd say we just delete it, rather than covert it over to rem.

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


3 months ago

#19 @audrasjb
3 months ago

  • Keywords needs-testing added

@kjellr
3 months ago

#20 @kjellr
3 months ago

Added 47498.4.diff, which removes that unused padding rule mentioned above.

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


3 months ago

@afercia
3 months ago

#22 @afercia
3 months ago

  • Keywords needs-testing removed

47498.5.diff quickly refreshes the patch after recent line numbers changes.

#23 @afercia
3 months ago

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

In 46248:

Accessibility: Improve and modernize user interface controls. Sixth part: allow checkboxes and radio buttons to scale with text.

  • uses a SVG icon for checkboxes
  • uses CSS rem relative units

Props kjellr, afercia, audrasjb.
Fixes #47498.

#24 @afercia
3 months ago

Looks like the Gutenberg checkboxes are impacted differently by the latest changes. It appears the Gutenberg checkboxes use different CSS? This should be addressed either on this ticket or on the Gutenberg GitHub. See screenshot below.

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


3 months ago

#26 @audrasjb
3 months 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

This ticket was mentioned in Slack in #core by garrett-eclipse. View the logs.


3 months ago

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


3 months ago

#29 @desrosj
3 months ago

Wanted to attach a few areas I noticed off-centered radio buttons. Some screenshots incoming.

It's strange because on certain pages, the radio fill is off to the top right, and others bottom right. A few pages (the discussion settings page), radio buttons within the same group alternate between the two.

@desrosj
3 months ago

Props @garrett-eclipse

#30 @garrett-eclipse
3 months ago

Thanks @desrosj and one thing I noticed was if you zoom out or in the issue goes away it seems it's only when I'm at 100% zoom I see the issue with radios.

#31 @afercia
3 months ago

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

#32 @afercia
3 months ago

  • Keywords needs-patch added; has-patch removed

Regarding the radio buttons blue dot not perfectly centered, looks like the CSS math is correct but it assumes screen pixels can be split :)

input[type="radio"]:checked::before {
	content: "";
	border-radius: 50%;
	width: 50%;
	height: 50%;
	margin: 25%;
	line-height: 0.76190476;
	background-color: #1e8cbe;
}

http://cldup.com/UHUwZOaWvo.png

The computed width / height of the blue dot is 7 pixels. Its margin computed value is 3.5 pixels. Browsers will round this value in different ways.

One option is to make the blue dot 1 pixel bigger and reduce the margin by 1 pixel. However, with percentage values this may still produce rounded values when zooming in / out.

Since the base size (the radio button) is expressed in rem, I'd try to use rem also for the blue dot.

width: 0.5rem; /* 8 pixels */
height: 0.5rem; /* 8 pixels */
margin: 0.1875rem; /* 3 pixels */

A quick patch and some testing would be nice :)

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

@afercia
3 months ago

#33 @afercia
3 months ago

  • Keywords has-patch added; needs-patch removed

47498.6.diff improves the centering of the radio buttons "blue dot".

Some testing would be nice :) In Firefox, using View > Zoom > Zoom Text Only, at some zoom levels the blue dot won't be perfectly centered. Firefox will round the values anyway. Not sure there's much that can be done but I'd say it's a very minor thing.

#34 @afercia
3 months ago

In 46345:

Accessibility: Improve and modernize user interface controls: Improve the radio buttons blue dot alignment.

Props desrosj, garrett-eclipse, afercia.
See #47498.

#35 @kjellr
3 months ago

Thank you for digging into that problem, @afercia!

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


2 months ago

#37 @Cybr
2 months ago

As mentioned in comment:9, using content:<> removes the possibility of styling the checkmarks. For example, their color. Is there no alternative method that would allow admin-schemes to inherit the vector graphics without having to reintroduce them?

#38 @afercia
2 months ago

@Cybr I'm not sure I can follow. The checkboxes "checkmark" works with color schemes. See screenshot below.
Also, plugins can override the content CSS property if they want.

@afercia
2 months ago

Checkbox with the Midnight color scheme.

#39 @Cybr
2 months ago

@afercia what I tried to convey is that changing the color now requires a custom SVG reimplementation via the content:<url()> field.

Before, with the Dashicon glyphs, we could easily affect it by changing one property (color:<>), instead of rewriting the whole thing.

When the checkmark-SVG changes (for any unforeseeable reason) in the future, the admin-theme-maintainer will have to address that. This amounts to a lot of unnecessary work and discrepancy between versions. There's one big plugin in the wild that is already affected: bbPress, with their Evergreen and Mint themes.

#40 @afercia
2 months ago

  • Keywords needs-dev-note added

Thanks for clarifying. So the checkbox change will need a dev note on a Make post.

However, I wouldn't say overriding the content CSS property would be a "a lot of unnecessary work". Unless I'm missing something, plugins that provide their own custom color schemes are not required to use the new SVG. That would be recommended but if they want to keep using their own implementation they just need to make sure to use a selector with higher specificity and keep using content: "\f147";.

Worth also noting that Gutenberg already uses SVGs for all its icons and there's a long standing plan to remove all font icons from core in favor of SVGs.

#41 @audrasjb
2 months ago

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

Closing this as fixed. A specific dev note will follow to communicate about comment 39 possible issue.

Note: See TracTickets for help on using tickets.