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

[kjellr]

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:

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.

2. 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:

[afercia]

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

[afercia]

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

[afercia]

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.

[kjellr]

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!

[afercia]

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:

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 :)

[kjellr]

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!

[afercia]

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]

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:

[afercia]

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]

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.

[kjellr]

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

[afercia]

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

[afercia]

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.

[afercia]

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.

[audrasjb]

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

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

[desrosj]

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]

Props @garrett-eclipse

[garrett-eclipse]

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.

[afercia]

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;
}

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 :)

[afercia]

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.

[afercia]

In 46345:

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

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

[kjellr]

Thank you for digging into that problem, @afercia!

[Cybr]

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?

[afercia]

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

Checkbox with the Midnight color scheme.

[Cybr]

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

[afercia]

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.

[audrasjb]

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

[desrosj]

Dev note: ​https://make.wordpress.org/core/2019/10/18/noteworthy-admin-css-changes-in-wordpress-5-3/

[SergeyBiryukov]

#38150 was marked as a duplicate.

[SergeyBiryukov]

Follow-up: #55768