Form controls now 40px by default; Navigation component removed

1. 40px default size for form controls
   1. What changed
   2. What to do
   3. Affected components
   4. Not included
2. Changes for consumers styling with Emotion
3. Remove Navigation
4. Remove __experimentalApplyValueToSides

40px default size for form controls

Starting in WordPress 7.1, @wordpress/components form controls use a 40px default height unconditionally. The opt-in __next40pxDefaultSize prop is no longer needed and has no runtime effect when passed.

This completes the rollout that followed the soft deprecation in WordPress 6.8. The prop was introduced in WordPress 6.7 so plugins could opt in early. Since 6.8, components that had not opted in logged a console warning.

What changed

• Affected components now render at 40px by default without the prop.
• Passing __next40pxDefaultSize is ignored at runtime.
• Passing __next40pxDefaultSize={ false } no longer opts out to the previous 36px height.
• On BorderBoxControl, BorderControl, FontSizePicker, and ToggleGroupControl, the size prop is also deprecated and has no effect.

What to do

Remove __next40pxDefaultSize from your component usage. No replacement prop is needed.

If you were passing size="__unstable-large" on the components listed only to get 40px height, remove that as well.

Affected components

For links to the code changes, see tracking issue #65751.

@wordpress/components

BorderBoxControl, BorderControl, BoxControl, ComboboxControl, CustomSelectControl, FontSizePicker, FormFileUpload, FormTokenField, FocalPointPicker, InputControl, NumberControl, QueryControls, Radio, RangeControl, SearchControl, SelectControl, TextControl, ToggleGroupControl, TreeSelect, UnitControl

@wordpress/block-editor

FontAppearanceControl, FontFamilyControl, LetterSpacingControl, LineHeightControl

Not included

This rollout covers form controls only. Button still uses the opt-in prop and is unchanged.

---

Changes for consumers styling with Emotion

A long-running migration has kickstarted in the @wordpress/components package, with the goal of refactoring all Emotion-based styles to SCSS modules.

Most consumers should not need to change anything, but if you do use Emotion to style your components, there are two migration details for code that relied on Emotion-specific behavior:

• View still accepts the legacy css prop for type compatibility, but it is now a no-op. Use style for inline styles or className for CSS-based styling.
• When using cx() with Emotion css() fragments, compose source-order-dependent fragments into a single css() call before passing them to cx(). Passing separate fragments can change override order now that View no longer renders through Emotion.

Example:

const classes = cx(
	css(
		baseStyles,
		condition && overrideStyles
	),
	className
);

This keeps shorthand/longhand overrides and nested-selector overrides in one generated class, preserving the intended cascade order.

The affected components are:

• Divider
• Surface
• Truncate
• View
• Flex
• Spacer

The list is expected to grow as the migration continues. Follow #66806 for more details.

---

Remove Navigation

Starting in WordPress 7.1, the deprecated Navigation component and its subcomponents are removed from @wordpress/components (#78529).

The component has been deprecated since WordPress 6.8. Use the Navigator component instead.

---

Remove __experimentalApplyValueToSides

Starting in WordPress 7.1, the __experimentalApplyValueToSides utility is removed from @wordpress/components (#78528).

The utility has been deprecated since WordPress 6.8. BoxControl itself is unaffected.

---

Co-authored by @0mirka00 and @mciampini.

Props to @aduth for review.

#7-1, #dev-notes, #dev-notes-7-1