Skip to content

fix(php-transformer): recognize paragraph-labelled menus inside custom-element hosts - #2245

Merged
chubes4 merged 5 commits into
trunkfrom
fix/desktop-menu-navigation
Sep 26, 2026
Merged

chubes4 merged 5 commits into
trunkfrom
fix/desktop-menu-navigation

Conversation

@chubes4

@chubes4 chubes4 commented Sep 26, 2026 •

Copy link
Copy Markdown
Contributor

Problem

A horizontal desktop menu whose item labels are wrapped in <p> inside the anchors was imported as escaped HTML in a companion block attribute. The Site Editor could edit the mobile core/navigation only.

After that menu became a real core/navigation, its items started at the container's leading edge (x=580) instead of the source/baseline position (x=733).

Root cause

Builders wrap an ordinary <nav> in a presentation-only custom element. That host is not a menu, but at depth it is captured as a generated companion, so paragraph-wrapped labels never become core/navigation-link blocks.

Once the landmark is recognized, the generated list is a flex container. It inherits an ancestor column and wraps, and core's default packing is flex-start. The source list is a block of inline items packed with text-align: right (or a row flex list packed with justify-content). That declaration was dropped, so the items started at the box edge. Setting layout.justifyContent alone does not fix it: on a wrapping column, justification packs the cross axis.

Fix

Before companion capture, if a custom element's only element child is a <nav> the existing navigation recognizer claims, lower that landmark to core/navigation and keep host id/class/style on a layout shell. No platform selectors.

Carry the list's horizontal packing onto the navigation as layout.justifyContent, and project flex-direction: row plus the matching justify-content onto that navigation's container only, scoped to the source list's own classes so other menus are unchanged.

Both viewport menus remain separate core/navigation blocks. Shared wp_navigation binding is #2246.

Regression test

php tests/unit/paragraph-label-desktop-menu.php

Fails before (unfixed host recognition, git stash of the recognition fix):

FAIL: shallow layout wrapper materializes the paragraph-labelled menu as core/navigation
FAIL: deep layout wrapper materializes the paragraph-labelled menu as core/navigation
Paragraph-label desktop menu: 8 failed, 3 passed

Fails before the packing projection (recognition present, projection stashed):

FAIL: shallow layout wrapper keeps the list text-align packing as navigation justification
FAIL: deep layout wrapper keeps the list text-align packing as navigation justification
Paragraph-label desktop menu: 2 failed, 11 passed

Fails before the scoped container rule (unscoped projection stashed):

FAIL: shallow layout wrapper projects the list packing onto that navigation container only
FAIL: deep layout wrapper projects the list packing onto that navigation container only
Paragraph-label desktop menu: 2 failed, 13 passed

Passes after:

Paragraph-label desktop menu passed: 15 assertions

Also passed: php tests/unit/navigation-layout-default.php, php tests/unit/navigation-vertical-orientation.php, php tests/unit/navigation-hidden-menu-hoist.php, php tests/unit/custom-block-generator.php.

Verification

Rebased onto trunk after #2243. Fresh import with SSI origin/main (9c83decd, v1.17.23) paired to this HEAD (9e35ea27e).

Desktop item x, source/baseline/fix. The #2243 baseline renders the preserved source list (text-align: right, inline-block items) and matches the source position called out in review.

viewport item source/baseline previous fix this fix
1440 Home 733 580 733
1440 Blog 1002 — 1002
1440 Shop 1051 — 1051
1440 Events 1103 — 1103
1440 Contact 1164 — 1164
768 Home 61 — 61

All measured desktop item deltas vs baseline are 0px. One visible header. First link y=45 at 1440 and 768.

At 390 the desktop menu stays hidden. Opening the mobile menu shows the same item positions as the baseline (Home x=138, Shop x=139, Contact x=134).

Saving a desktop navigation-link label from Blog to Journal (the same block-attribute write the Site Editor performs) renders Journal at x=1002, y=45. The mobile block is a separate core/navigation and is unchanged. Shared entity binding remains #2246.

Fixes #2244

AI disclosure: implemented by xAI Grok 4.7 via OpenCode (opencode run), orchestrated and reviewed by Claude (Anthropic).

@chubes4

chubes4 commented Sep 26, 2026

Copy link
Copy Markdown
Contributor Author

Review: regression test verified in the cook report; requesting changes before merge — desktop menu items shift left (x=580 vs 733 in the baseline/source). Please rebase on trunk (#2243 merged) and restore item geometry. Shared desktop/mobile menu entity tracked separately in #2246.

AI disclosure: review by Claude (Anthropic) via OpenCode.

…m-element hosts

A presentation-only custom element wrapping a nav was captured as companion
HTML before NavigationPattern could see the landmark, so paragraph-wrapped
menu labels never became editable navigation links.
…nition

A custom-element nav that also carries a display:none accessibility hint
must stay on the path that preserves that hint, instead of being replaced
by a navigation block that drops it.
A block list's text-align and a row flex list's justify-content were
dropped when the list became a flex core/navigation, so items started
at the container edge instead of the source position.
layout.justifyContent packs a wrapping column on the cross axis, so a
right-aligned list still started at the container edge. Restate the
source packing as a row on the generated list.
A global row rule also right-aligned other menus. Hang the packing
declarations off the source list's own classes.
@chubes4
chubes4 force-pushed the fix/desktop-menu-navigation branch from f2b17f6 to 9e35ea2 Compare September 26, 2026 18:16
@chubes4
chubes4 marked this pull request as ready for review September 26, 2026 19:25
@chubes4
chubes4 merged commit 946f0af into trunk Sep 26, 2026
10 checks passed
@chubes4
chubes4 deleted the fix/desktop-menu-navigation branch September 26, 2026 19:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Desktop menu imports as escaped HTML inside a layout block, so the Site Editor can only edit the mobile menu

1 participant