-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Description
When submenus are set to open on click, Submenu blocks have inconsistent link editing behavior: the Link button is hidden in the block toolbar (canvas) but the "Link to" control remains available in the sidebar. We need to decide on the intended behavior and enforce it consistently in both places.
The inconsistency
| Location | When submenus open on click |
|---|---|
| Block toolbar (canvas) | Link button hidden ✓ (per original design) |
| Sidebar (Settings → Link to) | Link editing allowed ✗ (contradicts design) |
The toolbar correctly implements the original design ("no link option" in click mode). The sidebar does not—it still allows adding and editing links. Submenu blocks can store a URL that may not be used when the parent renders as a <button>.
Design decision needed
The original a11y-driven design: "If the submenu opens on click, the item can be a button, and there should be no option to link somewhere."
Two paths to consistency:
-
Option A: No links in click mode (align with original design)
- Keep toolbar Link button hidden ✓
- Hide or disable the sidebar "Link to" control when
openSubmenusOnClickis true - Clear any existing URL when switching to click mode (or on save, don't output it)
-
Option B: Links allowed in click mode (revise the design)
- Show the Link toolbar button
- Keep sidebar "Link to" control
- Clarify frontend behavior: when parent is a button, how is the stored URL used? (e.g. first child, fallback, etc.)
Historical context
When: The Link toolbar conditional was introduced in the original Submenu block—PR #33775, merged September 13, 2021 (Gutenberg 11.6).
Why: Intentional a11y design. When submenus open on click, the parent is a <button> (disclosure widget), not a link. The design rationale: "there should be no option to link somewhere" (talldan, PR #33351).
Steps to reproduce
- Create or edit a Navigation block
- Set Submenu behavior → "Open submenus on click"
- Add or select a Submenu block
- Observe: Link button missing in toolbar, but "Link to" control visible and editable in sidebar
Proposed resolution
Decide which option (A or B) to adopt, then implement consistently. Option A aligns with the original a11y design; Option B would require design/a11y review to ensure the parent-as-button model still makes sense when links are supported.