Add xl border radius token for page shell surfaces.

[jameskoster]

What

Adds --wpds-border-radius-xl to the WPDS border radius scale and uses it on outer admin page shell surfaces.

Token & docs

• New xl step in packages/theme/tokens/border.json and regenerated prebuild artifacts
• Documented in packages/theme/docs/tokens.md and packages/theme/CHANGELOG.md

Consumers

• Boot: boot-layout__stage, boot-layout__inspector, and boot-layout__canvas (desktop); view-transition pseudo-elements
• Site editor: .edit-site-layout__area and .edit-site-layout:not(.is-full-canvas) .edit-site-layout__canvas .edit-site-resizable-frame__inner-content
• Storybook: theme example application mock page chrome

Why

The WPDS design language calls for radius to scale with container size. However, page shells and contained surfaces (Card, Notice) share an 8px radius, so when the latter are nested within the former, the hierarchy is broken. See the Gutenberg Experiments page as an example.

Extending the scale upward (rather than shrinking cards/notices) keeps lg aligned with the existing guidance for cards and modals.

How

1. Token: xs → sm → md → lg → xl via Terrazzo; run npm run build:tokens in @wordpress/theme.
2. Shells: Replace hardcoded 8px / $radius-large on outer layout chrome with var(--wpds-border-radius-xl).
3. Nested surfaces: No changes to @wordpress/ui Card/Notice (still lg).

Screenshots

Before	After

Note the radius of the shell is now one step larger than the radius of the nested cards.

Test plan

• Storybook → Design System/Theme/Theme Provider/Example Application — page chrome is more rounded than inner Card
• Storybook or local app → boot routes with Card/Notice inside stage — parent radius visibly larger than card
• Site editor (non–full-canvas) — preview frame and layout area use 12px corners; full-canvas mode unchanged
• Confirm dashboard widget tiles still match Card lg (8px)
• npm run build / theme token build if CI requires fresh prebuild

[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: jameskoster <[email protected]>
Co-authored-by: aduth <[email protected]>
Co-authored-by: ciampo <[email protected]>
Co-authored-by: jasmussen <[email protected]>

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

[aduth]

LGTM 👍 Logic tracks, verified in Site Editor & Fonts page, and searched other instances of border-radius in boot, edit-site, and admin-ui.

[github-actions]

Size Change: +63 B (0%)

Total Size: 8.59 MB

📦 View Changed

Filename	Size	Change
build/modules/boot/index.min.js	52.7 kB	+15 B (+0.03%)
build/styles/edit-site/style-rtl.css	22.1 kB	+24 B (+0.11%)
build/styles/edit-site/style-rtl.min.css	18.2 kB	+3 B (+0.02%)
build/styles/edit-site/style.css	22.1 kB	+17 B (+0.08%)
build/styles/edit-site/style.min.css	18.2 kB	+4 B (+0.02%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in c293deb.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/27413277646
📝 Reported issues:

• [Flaky Test] Should save the changes #78689 in /test/e2e/specs/editor/plugins/wp-editor-meta-box.spec.js
• [Flaky Test] shouldn't conflict with server-side autosave #78706 in /test/e2e/specs/editor/various/autosave.spec.js

[jasmussen]

Not blocking this. But a brief moment of pause and reflection—the math checks out, but I think it's worth asking whether the page should be so rounded after all.

Consider that we are looking to potentially replace the default 2px corner radius for buttons and inputs with 4px, which whould shift the entire range. Presumably we'd be looking at a 16px outer corner radius for the page itself. Does that get too bubbly?

I suspect the answer is: no, it's fine. But is there a way we can quickly gut-check this with a sketched visual before we land this?

[jameskoster]

I don't think the value of a token in the default scale needs to prescribe the value in a different scale.

In other words, if the xl token in the default scale is 12px, that doesn't necessarily mean it needs to be 16px in the next scale up. The default progression might be 2 → 4 → 8 → 12; the next could be 4 → 6 → 10 → 14, or even 3 → 5 → 9 → 13. We can choose. As the lower end of the scale gets more rounded we could even taper the upper-end to reduce bubblyness, e.g. 6 → 9 → 12 → 15.

If we agree the new xl token is warranted then what I'd like to do is merge this PR then refine the per-scale values in #78913 (which includes a story to easily test these details).

[ciampo]

Technically, this is good to go after remaining feedback is addressed + a rebase.

Merging will depend on design feedback

[jameskoster]

I see a 👍 from @jasmussen, but will wait for a green check before merging.

[ciampo]

We may want to rebase, move CHANGELOG to latest unreleased section before merging

[jameskoster]

I'm going to merge this as it closes a gap in the tokens exposed by a genuine need in the design language. We can continue to iterate as needed :)