Adopt surface-width design tokens for Dialog, Notice, and Modal widths

[jameskoster]

Follow-up to #76047.

What

Adopt --wpds-dimension-surface-width-* design tokens for component width constraints in the UI and components packages.

Before	After

Why

The @wordpress/theme package recently added a surface-width token scale to standardize surface/container widths across the design system. Several components -- Dialog, Notice, and Modal -- were using hardcoded pixel values for their width constraints. Aligning these with the token scale ensures consistency, makes future width adjustments easier to coordinate, and reduces the risk of drift between the newer UI package and the legacy components package.

How

• UI Dialog (packages/ui/src/dialog/style.module.css): Replaced five hardcoded pixel values with var(--wpds-dimension-surface-width-*) custom properties. Updated JSDoc in types.ts accordingly.
• UI Notice (packages/ui/src/notice/style.module.css): Resolved a TODO about replacing 320px with a theme token. Since container queries don't support var() (womp womp), the value remains hardcoded with a comment documenting its alignment with --wpds-dimension-surface-width-sm.
• Components Modal (packages/base-styles/_variables.scss): Updated the $modal-width-* SCSS variables to match the token scale values. Added comments referencing the corresponding tokens. Downstream consumers (link-control, url-popover, page-patterns) inherit these changes with minor visual adjustments.

Dialog/Modal width changes

Size	Before	After	Token
min-width (no size)	350px	320px	--wpds-dimension-surface-width-sm
small	384px	400px	--wpds-dimension-surface-width-md
medium	512px	560px	--wpds-dimension-surface-width-lg
large	840px	960px	--wpds-dimension-surface-width-2xl

Note

I can go either way between mapping large to xl(720px) or 2xl (960px), with a slight preference for 2xl.

Note: Other components in the components package (e.g. Snackbar, Guide) also have hardcoded widths that could potentially align with this token scale. I'm open to adopting the tokens for these components in this PR too, we'll just need to decide on the values.

Testing instructions

• npm run storybook:dev
• Check the Modal and Dialog stories; observe the updated sizes
• Smoke test modals in the site editor

[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 <jameskoster@git.wordpress.org>
Co-authored-by: mirka <0mirka00@git.wordpress.org>

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

[github-actions]

Flaky tests detected in 178f98e.
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/23057432486
📝 Reported issues:

• [Flaky Test] Should render and migrate legacy openSubmenusOnClick blocks #75559 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js

[mirka]

Any reason you opted to keep using the Sass variables instead of using the theme tokens directly? Also for the usages in block-editor and edit-site.

[mirka]

Should we remove this comment now?

gutenberg/packages/components/src/modal/style.scss

Lines 91 to 93 in d660ae4

	// The following widths were selected to align with existing baselines
	// found elsewhere in the editor.
	// See https://github.com/WordPress/gutenberg/pull/54471#issuecomment-1723818809

[mirka]

I feel like we should stop mentioning exact pixel values in documentation. The values aren't part of the contract, and are variable by nature.