Modal Block: Editor/front-end styling inconsistencies and UX issues

[allancole]

Description

The modal block has several issues related to styling consistency between the editor and front-end, as well as editor UX problems that make the block difficult to use intuitively. The "open modal" trigger button renders differently in the editor vs front-end, uses incorrect styles, and has unexpected layout behavior.

Current Behavior

1. Open Modal Button Styling Mismatch

• In editor: The open modal button appears as plain text with no button styling
• On front-end: The button renders with visible button styles, but these are browser default styles rather than inheriting the theme's button styles

2. Sidebar Input Fields Lack Visual Affordance

• The "Modal description" field in the block sidebar appears twice:
  • One instance is a label/title (non-editable)
  • The second instance is an editable input field, but it looks identical to the label
• There is no visual distinction (border, background, input styling) to indicate the field is editable
• Users may not realize they can edit this text until they accidentally click it

3. Button Width Breaks Content Area on Front-end

• In editor: The open modal button respects the content area width and aligns properly
• On front-end: The button extends beyond the content area as if it has a wide or full-width setting applied
• Workaround: Placing the button inside a Group block constrains it properly

Expected Behavior

1. Button Styling Consistency:

   • The open modal button should display with button styling in the editor (WYSIWYG)
   • Front-end button should inherit theme button styles (from theme.json or global styles), not browser defaults

2. Editable Fields Should Look Editable:

   • Input fields in the sidebar should have visual affordance (border, background color, or other indicator) consistent with other Gutenberg block controls
   • Users should immediately recognize which fields are editable

3. Consistent Width Behavior:

   • The open modal button should respect the content area width on the front-end, matching the editor preview
   • Should not require wrapping in a Group block to achieve expected layout

Editor	Frontend	Sidebar fields

Steps to Reproduce

Button Styling Issue:

1. Add a Modal block to a page
2. Observe the "open modal" button appears as plain text in the editor
3. Save and view the front-end
4. Observe: Button has styling, but it's browser defaults (not theme styles)

Sidebar UX Issue:

1. Add a Modal block and select it
2. Open the block settings sidebar
3. Look for "Modal description" field
4. Observe: Two text elements appear similar; it's unclear which is editable until clicked

Width Issue:

1. Add a Modal block directly to the page content area (not inside any container)
2. Save and view the front-end
3. Observe: Button extends beyond the expected content width
4. Edit the page, wrap the Modal block in a Group block
5. Save and view front-end again
6. Observe: Button now respects the content width

Acceptance Criteria

• Open modal button displays with button styling in the editor (matching front-end appearance)
• Front-end button inherits theme's global button styles (background, text color, padding, border-radius, etc.)
• Sidebar input fields have clear visual indication they are editable (consistent with core block patterns)
• Open modal button respects content area width on front-end without requiring a wrapper block
• Editor preview accurately represents front-end output (WYSIWYG)

Additional Context

• Button styling inheritance: The button should ideally use the same CSS custom properties or classes as the core Button block to ensure theme consistency. Reference: WCCOM-580 discusses similar inheritance issues.

• Sidebar UX pattern: Other core blocks use TextControl or similar components with visible borders/backgrounds for editable fields. The modal block should follow the same pattern.

• Width issue: This may be caused by missing block alignment attributes or incorrect CSS specificity on the front-end. The block likely needs explicit max-width or alignment handling.

• Issue Type: Bug (styling/layout) + UX Improvement (editor affordance)