fix(php-transformer): recognize paragraph-labelled menus inside custom-element hosts - #2245
Merged
Merged
Conversation
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
force-pushed
the
fix/desktop-menu-navigation
branch
from
September 26, 2026 18:16
f2b17f6 to
9e35ea2
Compare
chubes4
marked this pull request as ready for review
September 26, 2026 19:25
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 mobilecore/navigationonly.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 becomecore/navigation-linkblocks.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 withjustify-content). That declaration was dropped, so the items started at the box edge. Settinglayout.justifyContentalone 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 tocore/navigationand 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 projectflex-direction: rowplus the matchingjustify-contentonto that navigation's container only, scoped to the source list's own classes so other menus are unchanged.Both viewport menus remain separate
core/navigationblocks. Sharedwp_navigationbinding is #2246.Regression test
php tests/unit/paragraph-label-desktop-menu.phpFails before (unfixed host recognition,
git stashof the recognition fix):Fails before the packing projection (recognition present, projection stashed):
Fails before the scoped container rule (unscoped projection stashed):
Passes after:
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.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/navigationand 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).