WordPress 7.1 stops copying Navigation block font-size settings onto each child item. The fix prevents relative units such as `1.5em` from multiplying at every submenu depth, but themes that target font-size classes directly on `li` elements can lose a selector they expected.
Use this before upgrading block themes, navigation extensions, mega menus, or sites with nested dropdowns, responsive menus, custom font-size presets, or CSS that targets child Navigation classes.
Quick answer
Create a three-level menu fixture with named presets, custom pixel values, and relative units. Capture WordPress 7.0.2 and 7.1 computed font sizes in the editor and frontend at desktop plus mobile widths. Fix theme selectors to rely on inheritance unless the design intentionally requires child-level classes.
What to check first
- Build at least three menu depths with Navigation Link, Submenu, Page List, and Home Link blocks.
- Test named font-size presets, custom `px`, `rem`, and `em` values on the parent Navigation block.
- Record computed `font-size`, matching CSS rule, and class list for each depth before and after the upgrade.
- Open and close desktop dropdowns plus the mobile overlay while checking clipping, wrapping, focus, and tap targets.
- Search theme and plugin CSS for selectors such as `.wp-block-navigation-item.has-*-font-size`.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build the nested fixture | Build at least three menu depths with Navigation Link, Submenu, Page List, and Home Link blocks. | Nested items inherit the intended size without multiplication. |
| Capture the old baseline | Test named font-size presets, custom `px`, `rem`, and `em` values on the parent Navigation block. | Theme font-size presets still render at desktop and mobile widths. |
| Compare computed styles | Record computed `font-size`, matching CSS rule, and class list for each depth before and after the upgrade. | Keyboard and touch users can open every submenu without clipped labels. |
| Update narrow theme selectors | Open and close desktop dropdowns plus the mobile overlay while checking clipping, wrapping, focus, and tap targets. | Editor and frontend screenshots match the approved design fixture. |
Test scenarios to run
Run the same controlled fixture across these branches. Record the expected result before the test so a surprising response is visible immediately.
| Scenario | Fixture | Expected result |
|---|
| Named preset | Parent Navigation uses the approved medium preset | Every depth resolves to the same approved computed size |
| Relative unit | Parent uses 1.5em with three submenu depths | Children inherit without 1.5x multiplication at each level |
| Child override | One nested link has its own explicit size | The intentional child size wins without affecting siblings |
| Mobile overlay | Long labels at 390 pixels with two expanded submenus | Text wraps cleanly and focus remains visible |
Why this usually happens
- Relative `em` values compound when copied to both parent and descendants.
- Legacy CSS can depend on a child class instead of inherited text styling.
- Editor and frontend stylesheets can resolve the same selector differently.
Field notes
- Capture screenshots with the same viewport, zoom, font load state, and menu content.
- Include a long menu label and a nested item with an icon.
- Test logged-in and logged-out pages because admin-bar width can alter wrapping.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
// Browser console, run for each menu depth.
[...document.querySelectorAll('.wp-block-navigation-item')].map((el, depth) => ({
depth,
label: el.querySelector('a')?.textContent.trim(),
fontSize: getComputedStyle(el).fontSize,
classes: el.className
}));
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Build the nested fixture
- Capture the old baseline
- Compare computed styles
- Update narrow theme selectors
- Retest responsive navigation
Decision rule
Hold the upgrade if approved menu typography changes, submenu text compounds, labels clip, focus becomes hidden, or editor and frontend sizes do not match.
What to tell the client or owner
Share the page URL, menu depth, viewport, WordPress build, theme, selected font preset, computed size, matched rule, screenshot, and expected design token.
Production verification checklist
- Nested items inherit the intended size without multiplication.
- Theme font-size presets still render at desktop and mobile widths.
- Keyboard and touch users can open every submenu without clipped labels.
- Editor and frontend screenshots match the approved design fixture.
Mistakes to avoid
- Do not compare screenshots before web fonts finish loading.
- Do not restore legacy propagation globally to fix one theme selector.
- Do not test only a one-level menu.
- Do not ignore focus outlines and touch target size while reviewing typography.
Questions teams ask during testing
Will every Navigation block look different?
No. The main risk is nested menus using relative units or custom CSS that expects font-size classes on child elements.
Should we add the compatibility filter from the dev note?
Use it only when the theme intentionally depends on child-level propagation and a narrow CSS correction is not suitable.
Why test the mobile overlay?
Text wrapping, container width, focus, and submenu expansion can expose a regression that is invisible in the desktop header.
When HandL WP should help
HandL WP can build a navigation fixture, compare computed styles across versions, correct the narrow theme rule, and verify desktop, mobile, keyboard, and frontend parity.
If this is active on a production site, test a WordPress 7.1 theme upgrade.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references