Guidelines: Improvements to the UX

[aswasif007]

What?

Related issue: #75260

Improves content guidelines UX: adds a reusable remove/clear confirmation modal, uses it for removing block guidelines (from the list and from the edit modal) and for clearing category guidelines, renames the add/edit block guideline modal header, uses default font weight for modal headers, and extracts related CSS into component-level stylesheets.

Why?

• Consistency and safety: Removing or clearing guidelines was previously immediate. A confirmation step reduces accidental data loss and matches user expectations for destructive actions.
• Reuse: The same confirmation pattern is needed in multiple places (block guidelines list, block guideline edit modal, category guideline form). Extracting a shared component keeps behavior and copy consistent.
• Clarity: Shorter modal title ("Add/Edit guidelines" instead of "Add/Edit block guidelines") and default font weight for modal headers improve readability and alignment with design.

How?

• RemoveGuidelineConfirmation component
  New reusable modal component that accepts a title (modal header), children (body content), onClose, onConfirm, optional isBusy, and optional actionLabel. Used for both "Remove" and "Clear" flows.
• Block guidelines
  • List view: "Remove" row action opens the confirmation modal; on confirm, block guidelines are cleared and saved.
  • Edit modal: "Remove" button opens the same confirmation modal; on confirm, guideline is cleared and the modal closes on successful save.
• Category guidelines (accordion form)
  "Clear guidelines" button opens the confirmation modal; on confirm, that category’s guidelines are cleared and saved. Success notice: "Guidelines cleared."
• Copy and styling
  • Add/Edit block guideline modal title renamed to "Add guidelines" / "Edit guidelines".
  • Modal header font weight uses default (500) via shared confirmation styles.
• CSS
  • Confirmation modal uses class remove-guideline-confirmation and has its own SCSS file.
  • Accordion form styles moved into guideline-accordion-form.scss and imported by the form component.

Testing Instructions

1. Go to http://localhost:8888/wp-admin/admin.php?page=gutenberg-experiments and tick the Guidelines
2. Go to http://localhost:8888/wp-admin/options-general.php?page=guidelines-wp-admin
3. Block guidelines – list
   • Add guidelines for a block, then use the "Remove" action on a row.
   • Confirm a modal appears with title "Remove block guidelines" and the block name in the message.
   • Cancel: modal closes, guidelines unchanged.
   • Remove: guidelines are removed and a success notice appears.
4. Block guidelines – edit modal
   • Open "Edit guidelines" for a block that has guidelines.
   • Click "Remove".
   • Confirm the same confirmation modal appears.
   • Cancel: confirmation closes, edit modal stays open.
   • Remove: guideline is removed and the edit modal closes on success.
5. Category guidelines (accordion)
   • Expand a category (e.g. "General") that has guidelines.
   • Click "Clear guidelines".
   • Confirm modal title is "Clear guidelines" and the message references the category.
   • Cancel: modal closes, guidelines unchanged.
   • Clear: guidelines are cleared and "Guidelines cleared." snackbar appears.
6. Check that "Add guidelines" / "Edit guidelines" modal titles and modal header font weight look correct.

Testing Instructions for Keyboard

1. Navigate to Content Guidelines (Settings → Writing or equivalent).
2. Use Tab to focus the block guidelines list or an accordion section.
3. Use keyboard to open "Remove" or "Clear guidelines" (e.g. action menu or button).
4. Confirm the confirmation modal opens and focus moves into it.
5. Tab to "Cancel" and "Remove"/"Clear"; activate with Enter/Space.
6. Confirm focus is trapped in the modal until it is closed and that closing returns focus appropriately.

Screenshots or screencast

Before	After
N/A
N/A

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: aswasif007 <aswasif007@git.wordpress.org>
Co-authored-by: fditrapani <fditrapani@git.wordpress.org>
Co-authored-by: aagam-shah <aagam94@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[fditrapani]

Thanks for these updates @aswasif007! These are looking great.

We also discussed updating the Edit modal CTA to read "Save guidelines" to match these other updates.

[fditrapani]

Thanks for the update! looks good to me!

[aagam-shah]

Hey @aswasif007, appreciate the work here — the Modal → ConfirmDialog refactor is solid and everything else looks good!

One small thought: the <br /><br /> inside ConfirmDialog children — every other ConfirmDialog usage in the codebase passes a single string. The component internally wraps children in <Text> (a <span>), so <br /> tags work but go against the design. What if we combined it into one string instead?

{ sprintf(
    __( 'You are about to remove the block guidelines for the %s block. This can be undone from revision history.' ),
    selectedBlockLabel
) }

I think that'd be more consistent with how the rest of the codebase uses ConfirmDialog.

cc @fditrapani for visibility from the design side.

[aswasif007]

Thanks @aagam-shah !

If @fditrapani agrees that we can deviate from the design a bit, we can combine it into a single string.

[fditrapani]

What if we combined it into one string instead?...agrees that we can deviate from the design a bit, we can combine it into a single string.

No problem! That should be fine

[aswasif007]

Thanks @ramonjd and @aagam-shah. I've addressed all your feedbacks!

[aagam-shah]

Thanks for working on this and addressing the issue. LGTM 🚢

[ramonjd]

Not a blocker but maybe something to look at in a follow up.

handleSave is mostly an async op, right? The ConfirmDialog's isBusy never really shows, because the dialog is closed right away.

Like handleClearConfirm already does we could consider only closing ConfirmDialog when save completes in a finally block, for consistency.

[ramonjd]

Another for a follow up.

slug is from GUIDELINE_ITEMS?

slug isn't translated so it's probably better to use the title, otherwise you'll have mixed locales in the same string.