CheckboxControl: replace margin overrides with new opt-in prop

[brookewp]

What?

Replacing margin overrides with new opt-in prop __nextHasNoMarginBottom for useages of CheckboxControl in the Gutenberg codebase.

Why?

Part of this project: #38730
The tl;dr is BaseControl has a margin-bottom which makes it difficult to reuse and results in inconsistent use.

How?

By removing margin overrides in the CSS and adding the prop __nextHasNoMarginBottom.

To note, CheckboxControl in packages/edit-navigation/src/components/sidebar/manage-locations.js wasn't updated. I couldn't find this on the front end so I'm unsure if it's being used. It looks like it might be a paused project.

Testing Instructions

To test this, you'll need to look for the following checkboxes and ensure that the margin is the same as before (margin-bottom of 0) for the div with class components-base-control__field. Screenshots below are how it looks in core right now.

1. Create a new post and then go through the steps for each component:

For BlockManagerCategory and BlockTypesChecklist

1. Click on three dots in the top right corner of post editor
2. Then select 'Preferences'
3. Click on 'Blocks' and scroll down to 'Visible Blocks'
4. Ensure that the margins for the checkboxes are set to 0 as they were before for both the category and subcategories under 'Visible Blocks'

ForPostSticky and PostPendingStatus

1. Click on 'Post' in sidebar
2. Ensure that the margins for the checkboxes are set to 0 as they were before for both 'Stick to the top of blog' and 'Pending Review'

For HierarchicalTermSelector

1. Under 'Post' in the sidebar click on 'Categories'
2. Click 'Add new category' and add test category
3. Ensure that the margins for the checkboxes are set to 0 as they were before for listed categories

For PostComments and PostPingbacks

1. Under 'Post' in the sidebar click on 'Discussion'
2. Ensure that the margins for the checkboxes are set to 0 as they were before for 'Allow comments' and 'Allow pingbacks & trackbacks'

For EntityRecordItem

1. Add Navigation block to editor
2. Add link to menu
3. Click on 'Publish'
4. Ensure that the margins for the checkboxes are set to 0 as they were before under 'Navigation Menus'

For BlockLockModal

1. Add any block (can use the Navigation block from above) to the editor
2. Click on the three dots and then on 'Lock'
3. Ensure that the margins for the checkboxes in modal are set to 0 as they were before

For PostPublishPanel

1. Make a change to the post
2. Click on 'Publish'
3. Ensure that the margins for the checkboxes are set to 0 as they were before for 'Always show pre-publish checks'

Screenshots or screencast

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[mirka]

Thank you for the amazing testing instructions, it was a breeze to review!

Everything looks good, we can merge once you update the snapshots and add a changelog.

[mirka]

Not in this PR, but a good follow-up for these would be to move the Icon out of the CheckboxControl label (it doesn't make sense), and move these flex styles into the parent element so we can remove these hacky overrides on components-base-control__field.

(Same with block-manager)

[brookewp]

@mirka when I initially read your comment, I assumed it was related to accessibility. I've just tested with my screen reader and looked a bit into it, but I couldn't find anything. Would you mind sharing why it is best to move the icon out of the label (aside from the opportunity to remove the CSS overrides)?

[mirka]

Correct, it's not an a11y issue, just that there is no reason for the aria-hidden icon to be in the label. The main motivation is to remove the CSS override. I'll add some context in case some of it was missing:

Any consumer usage that reaches into and overrides the internal styling of a wp-component is inherently brittle. If BaseControl changes its structure or styling at some point, these BlockLock overrides could break in unexpected ways. We've been discouraging style hacks like this, since it actively harms our ability to make changes to wp-components without things breaking all over the place. It's doubly harmful because third-party devs often turn to the Gutenberg source code to learn how they should be building things.

So when things look like you might want to override internal wp-component styling, the decision flow would roughly be like:

1. Can I accomplish the same thing without adding a style hack? If so, that is always better.
2. Is this a common design pattern that will appear multiple times in the Gutenberg app? If so, consider proposing a change to the wp-component in question so it can flexibly handle more use cases out of the box.
3. If no to either of those questions, consider building your own component from scratch, or modifying your design so it works within the existing component limitations.

[brookewp]

Thank you for the detailed explanation! Very helpful! 🙌

[mirka]

Ah never mind about the changelog, this PR doesn't need one 😄

Good to go then! 🚀