Forms: Scale checkbox input with custom font sizes (FORMS-682)

[alinclamba]

Fixes #42446 | Part of pfln9p-2BB-p2 | FORMS-682 |

Proposed changes

• Change the SCSS selector anchor for the singular Checkbox and Consent input rules from .is-style-list to the field's own wrapper class (grunion-field-checkbox-wrap and grunion-field-consent-wrap). The new selectors target a class that's unconditionally emitted in the rendered HTML, so the rule reliably matches and the input gets font-size: inherit. Without the fix, the input keeps the browser-default font size when a custom font size is set.
• Four hunks in projects/packages/forms/src/contact-form/css/grunion.scss. Same selector count, same specificity (0,2,1), no PHP changes.

Root cause

The SCSS rule that gives input.checkbox its font-size: inherit (so its width: 1em resolves against the parent's font-size) is anchored on an .is-style-list ancestor. For Checkbox-Multiple and Radio that class is reliably saved, because they have a registered block style with is_default => true. For singular Checkbox, the equivalent class is set in field-checkbox/edit.js via setAttributes inside a __unstableMarkNextChangeAsNotPersistent() block, which prevents that next change from being serialized. Because users typically only edit the inner Option block's label after insertion — not the field-checkbox block itself — no subsequent setAttributes ever flushes the queued className, and is-style-list never reaches the saved post content. The class shows up in the editor but not in the rendered frontend HTML; the SCSS rule never matches; the input falls back to the browser-default font size.

Preset values (XXL, XL, L, M, S) escape the bug because the preset class (e.g. has-xx-large-font-size) is appended to the input's own class attribute via Contact_Form_Field::render() and resolved by WordPress' global preset CSS — independent of inheritance. Custom values produce only an inline style on the wrapper and label, which the input can't reach without font-size: inherit, so the bug only surfaces with custom values.

Side-effect: Consent

The singular Consent field shares the same SCSS selector groups in all four affected spots, and has the same __unstableMarkNextChangeAsNotPersistent pattern in its edit.js. In normal usage Consent escapes the bug, because users almost always trigger a subsequent setAttributes on the consent block (toggling Implicit/Explicit, editing the message, etc.) which flushes the queued is-style-list into saved post content — so the existing CSS selector matched. Consent's bug only surfaces if a user manually removes is-style-list from the block's Advanced CSS Classes, or otherwise prevents the className from persisting.

Even though the practical impact for Consent is small, the fix removes the fragility: the new selector anchors on a class that's unconditionally present in the rendered output, so Consent works regardless of how the block was edited. The change to Consent and the change to Checkbox are structurally one change — splitting the SCSS selector groups to fix only Checkbox would add lines and create an asymmetry that doesn't exist today.

Considered alternatives

• Registering an is-style-list block style for the singular Checkbox and Consent blocks. Rejected: it would fix new posts only — existing saved posts (without the className serialized) would stay broken.
• Emitting option_styles directly on the input element from render_checkbox_field() PHP. Rejected: broader change for the same outcome; the CSS selector swap delivers it in one motion.

Related product discussion/links

• Linear: FORMS-682
• Related: jetpack#41526 — HTML markup harmonization between Consent and Checkbox (separate scope, not addressed here).
• Originally noticed during PR Update field style controls to use tools panel and live in the styles tab #42278 — not introduced there.

Does this pull request change what data or activity we track or use?

No.

Testing instructions

Tested on a clean Jurassic Ninja sandbox (Twenty Twenty-Four, Jetpack 15.8-beta, only Jetpack + Akismet active), Chrome.

To reproduce the bug on trunk:

1. Add a Contact Form block with a Checkbox field inside.
2. Select the inner Option block, set Font Size to a custom value (e.g. 4.5rem) via the slider in the Block Inspector.
3. Publish and view the post on the frontend. Expected: label text is large, checkbox box stays at the browser-default ~13px.

To verify the fix:

1. Same steps. Expected: both label and checkbox box scale to the chosen size.
2. DevTools → inspect the input → Computed → font-size: should be the resolved clamp value (~45px for 4.5rem), not 13.333px.

Cases verified:

• Singular Checkbox + custom 4.5rem: box scales (45.59px on input, was 13.333px before fix).
• Singular Checkbox + preset XXL: still scales (regression).
• Singular Checkbox + no font size: unchanged (regression).
• Singular Consent (Explicit) + custom font size: box scales (45.04px). Note: reproducing the broken state required manually removing is-style-list from the Advanced CSS Classes panel — see "Side-effect: Consent" above.
• Multi-Checkbox + custom font size: still scales (regression).
• Single Choice (radio): skipped — the radio block does not expose a Font Size control in the Block Inspector (parent or per-Option), so the affected code path can't be exercised via UI. The selector swap is identical in shape to the Multi-Checkbox case, which was tested.
• pnpm jetpack test php packages/forms passes (CSS-only fix, no PHP test changes expected).

Coverage gaps for transparency:

• Tested in Chrome only. Safari spot-check was in my plan but I skipped it. The fix is a CSS selector swap with font-size: inherit resolving against the wrapper's clamp value, which is browser-agnostic in behavior, so the missed coverage is unlikely to surface a different result. Happy to add Safari verification before merge if a reviewer asks.
• Tested on Twenty Twenty-Four only. The fix targets Jetpack-emitted classes and doesn't depend on theme CSS, so a classic-theme spot-check (e.g. Twenty Twenty-One) is unlikely to differ. Same offer to add if requested.

Visual A/B

Singular Checkbox + custom 4.5rem (Row 3 in my testing)

Before fix:

After fix:

Consent (Explicit) + custom 4.5rem, with is-style-list removed from Advanced (Row 4)

Before fix:

After fix:

#jetpack-happy-ai-updates

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack), and enable the fix/forms-checkbox-text-size-scaling branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack fix/forms-checkbox-text-size-scaling

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report · JS report

[alinclamba]

Ran /jetpack-review-pr locally before opening. Findings: no code issues found.