admin-ui: let the Breadcrumbs nav shrink so long crumbs truncate

[dognose24]

What?

Closes #81297

Lets the admin-ui Breadcrumbs nav shrink (min-width: 0), so a long current crumb truncates with its existing ellipsis instead of widening the whole page into horizontal scrolling.

Note: this PR originally also gave the Page header's leading group min-width: 0. That half landed on trunk in #81954 (.header-lockup), so this PR has been rebased and reduced to the Breadcrumbs half, as suggested in #81301 (comment).

Why?

The Breadcrumbs nav is a flex item inside the Page header's leading group. With the flexbox default min-width: auto, a nowrap crumb's min-content propagates up the chain and forces the page wider than its container before the truncation styles that Breadcrumbs already ships (.current's ellipsis, the shrinkable li:last-child) can engage.

#81954 fixed the outer link of that chain (the header's leading group), but the nav itself still refuses to shrink, so the crumb keeps overflowing. Consumers currently have to patch this from outside with structural selectors (e.g. :has(> nav[aria-label]) { min-inline-size: 0 }), which breaks silently as soon as any wrapper — a display: contents one, for instance — lands between the header and the nav. See #81297 for the full analysis; the slot is also set to be reworked under #77039 / #77628, and this pins the propagation fix until those land.

How?

• breadcrumbs/index.tsx — the nav gains a root class.
• breadcrumbs/style.module.css — .root { min-width: 0; }.
• CHANGELOG.md — entry under Unreleased → Bug Fixes.

No behavior change for content that fits: min-width: 0 only removes the automatic minimum, it does not make anything smaller on its own.

Testing Instructions

1. Render an admin-ui Page with breadcrumbs whose last item is a long unbroken string, e.g.:

   <Page
   	breadcrumbs={
   		<Breadcrumbs
   			items={ [
   				{ label: 'Home', to: '/' },
   				{ label: 'VID_20260731_' + 'a'.repeat( 120 ) + '.mp4' },
   			] }
   		/>
   	}
   />

   (The Admin UI/Page → WithBreadcrumbs story with a long last label works as well.)
2. Narrow the viewport below the crumb's natural width.
3. Before: the page grows a horizontal scrollbar and the crumb never truncates. After: the crumb truncates with an ellipsis and the page keeps its width.

Note that the standalone Breadcrumbs stories truncate correctly even without this change — the defect only appears once the nav sits inside the Page header's flex chain.

Testing Instructions for Keyboard

Tab through the breadcrumb links before and after narrowing the viewport: link order, focusability, and visible focus outlines are unchanged — this PR only allows the existing flex chain to shrink, it adds no interactive changes.

Screenshots

Taken on the Admin UI/Page → WithBreadcrumbs story with the last crumb replaced by a long unbroken string (VID_20260731_aaa….mp4), viewport narrower than the crumb's natural width.

Before	After

Screencasts

Before

2026-08-07.11.50.03.mov

After

2026-08-07.11.49.08.mov

[ciampo]

Could we add screenshots (or even better, screencasts of the responsive behaviour) for both the issue and this PR? It's hard to understand exactly what's the issue and the solution proposed by reading the PR description

[dognose24]

Good call — I've added before/after screenshots to the PR description and mirrored them on #81297 (taken on the Admin UI/Page → WithBreadcrumbs story with the last crumb swapped for a long unbroken string, same viewport width in both shots).

One detail worth calling out: the standalone Breadcrumbs stories truncate correctly even without this change — the defect only appears once the nav sits inside the Page header's flex chain, which is exactly what the two min-width: 0 rules unblock.

Screencast of the responsive behaviour below: first clip is trunk (the crumb refuses to shrink and the page scrolls horizontally as the viewport narrows), second is this branch (the existing ellipsis engages and the page keeps its width).

Before

2026-08-07.11.50.03.mov

After

2026-08-07.11.49.08.mov

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dognose24 <dognose24@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ciampo]

With #81954 merged, we could rebase and redube this PR to:

• Add styles.root to the Breadcrumbs nav.
• Add .root { min-width: 0; }.
• Update the current Unreleased changelog.

[dognose24]

Thanks @ciampo — done. Rebased on trunk and reduced the PR to the Breadcrumbs half, since #81954 already gives the header's leading group min-width: 0 via .header-lockup:

• breadcrumbs/index.tsx: the nav gets styles.root.
• breadcrumbs/style.module.css: .root { min-width: 0; }.
• CHANGELOG.md: entry under Unreleased → Bug Fixes.

The page/header.tsx and page/style.module.css changes are dropped. PR title and description updated to match.

[ciampo]

Looking at these changes, they cause the current crumb to shrink, but that can also be the page's only visible h1.

At narrow widths or high zoom, long media and menu titles are clipped with no way to read the full text, which can be problematic.

I feel like this issue is going to be solved inherently when updating to using the recently added Breadcrumb component from @wordpress/ui, which correctly adds ellipses + tooltip in that scenario:

cc @simison to confirm my gut feeling here

[dognose24]

Thanks @ciampo — that's a fair point. Truncating the current crumb without any way to read the full text is a real regression for the h1 case, and the min-width: 0 alone doesn't address it.

Agreed that the @wordpress/ui Breadcrumb is the right fix here: its root already ships min-inline-size: 0, so the min-content propagation this PR targets goes away, and the truncated current item gets the tooltip and focusability that this PR lacks. Once Page renders breadcrumbs through it in #82384, this change has nothing left to fix.

I'll close this PR in favour of #82384 and leave #81297 open as the tracking issue until that lands, since the overflow is still reproducible on trunk today and consumers are still working around it from outside.

@simison — is there a rough timeline for #82384?