fix: expand interactive targets to the 48dp minimum

[k0ndee]

Motivation

Touch targets used to match the drawn box exactly: Checkbox 40×40, RadioButtonAndroid/RadioButtonIOS ~36×36 (20dp glyph + 8dp margin on Android, 24dp glyph + 6dp padding on iOS), IconButton 40×40, Chip's close icon 26×18.

MD3 instead grows the target around the component without resizing it, and only when the component is interactive - so a 40dp state layer stays 40dp visually but gains slop around it.

Each interactive component now computes its own hitSlop from its own fixed render-time size, via a new getMinInteractiveSizeHitSlop({ width?, height? }) utility. It returns the Insets needed to reach the 48dp minimum, or undefined if the component is already big enough. TouchableRipple itself does no measuring, it honors whatever hitSlop it's given. A caller-supplied hitSlop overrides the computed default, and a disabled component gets no slop at all.

This normalizes RadioButtonAndroid/RadioButtonIOS onto the same 40dp state layer as Checkbox/Switch (RadioButtonTokens.stateLayerSize), with glyph size/padding adjusted to stay centered. New per-component token files (Chip/tokens.ts, RadioButton/tokens.ts) hold the MD3 dimensions these computations derive from. The 48dp minimum itself is a local MIN_INTERACTIVE_SIZE constant in getMinInteractiveSizeHitSlop.ts - an earlier revision added it as a shared minInteractiveSize token on theme/tokens/sys/state.ts, but that was reverted per review feedback.

Two platforms, because one mechanism doesn't cover both:

• Native - the computed Insets pass straight through to Pressable's hitSlop, same as a caller-supplied one.
• Web - react-native-web dropped hitSlop support in 0.13.0, so TouchableRipple instead renders an aria-hidden, absolutely-positioned sibling sized from the same Insets, for the browser to hit-test. It renders before the children so it can never cover an interactive child. Switch doesn't go through TouchableRipple, so it carries its own equivalent webTouchTarget view.

A parent with overflow: 'hidden' clips the expanded target - which is why IconButton's hitSlop had never actually applied. So on web, the ripple now clips itself via its own inset, radius-matched container, rather than relying on the touchable or an ancestor.

That change pulls in a few more:

• IconButton's container drops overflow: 'hidden'; the radius moves to the overlay and touchable so they clip themselves. Its hardcoded hitSlop ({10}/{6} depending on TouchableRipple.supported) is replaced by the computed one. Since shape can no longer be read out of style (it may be an animated value on the UI thread, invisible to synchronous StyleSheet.flatten), IconButton now also accepts borderRadius/borderTop*Radius/etc. as plain props, so callers needing a custom shape (e.g. segmented ends) can apply it directly to the self-clipping overlay/touchable.
• SegmentedButtonItem now computes its own default hitSlop from content height (2 * paddingVertical + iconSize, never shorter than the label) - previously it only forwarded a caller-supplied hitSlop, with no floor of its own.
• The press underlay on iOS and older Android now takes the touchable's radius - it was square before, and only looked right because a parent clipped it.
• Chip's close button now fills the 34dp column the chip already reserved, instead of just the 26×18 icon.

Related issue

Follow-up to #5080 (fix: expand interactive targets to the 48dp minimum) - same change, rebased onto current main and updated per that PR's review feedback (the onLayout-based measurement was replaced with the static per-component computation described above).

Closes #5079.

Touches the same files as #5071 (fix: don't expose handler-less TouchableRipple as a disabled control), still open - no conflict today, but whichever lands second needs a look.

Button has the same clipped, non-applying hitSlop but is intentionally left unfixed here. Per review discussion on #5080, unclipping it is deferred to a follow-up on #5097 (Button MD3) once this merges. Both PRs touch __snapshots__/Button.test.tsx.snap; whichever lands second regenerates it.

Test plan

Lint, typecheck, and tests pass. A new TouchableRippleWeb.test.tsx pins the web target's style/ordering against the touchable's own bounds, a caller-supplied hitSlop, disabled, and the no-handler case.

The suite only renders a tree with no layout or hit testing, so it pins props, not behavior. Verified on device by tapping inside the expected slop and again past it:

	iOS 18.3	Android 15	web
Checkbox 40dp	48	48	48
RadioButton 40dp	48	48	48
IconButton 40dp	48	48	48
past the slop	miss	miss	miss
caller hitSlop wins	ok	ok	ok
disabled gets nothing	ok	ok	ok

Notes

• Chip's behavior changes: the right 34dp now fires onClose where it used to fire onPress. This matches MD3, where the primary action stops where the trailing action begins.
• borderless no longer clips content on web. It still clips the ripple, now via its own inset container instead of the touchable itself - the touchable can't clip without also clipping the touch target. Nothing in Paper depended on the old behavior (checked across 569 touchables on 15 screens); prop docs updated.
• Targets can now overlap, which is the MD3 default. On web, the later sibling wins the shared strip; reserve separate space instead if you'd rather avoid that.

Videos

Visual confirmation that TouchableRipple itself is unchanged before/after - only the hitSlop/touch target changed, not how the ripple looks or animates. Each pair is the same interaction recorded before and after this PR on the same platform.

Web

web_before.mov

web_after.mov

Android

android_before.mov

android_after.mov

iOS

ios_before.mov

ios_after.mov

[satya164]

Copied from my review on #5080. The layout-measurement feedback below has already been addressed in this PR. The remaining inline comments are copied unchanged.

Remove LLM generated comments. Only add comments where the code maybe unclear and it's necessary.

The touchable should not enforce a minimum hitSlop. Adding unnecessary onLayout everywhere has performance overhead. It should only accept hitSlop prop without layout measurement or minimums. The web version only needs to implement hitSlop since React Native Web doesn't support it.

The actual hitSlop should be passed by components where they are needed, e.g. checkbox. It's simpler and doesn't have require layout measurements.

The following original Chip comment is also already addressed here, since the constants now precede the component JSDoc:

These constants are added between the component and its JSDoc, which will break documentation generation for the component.

[satya164]

Applied by expanding outside the component's bounds

This is an implementation detail the constant here can't possibly know or control

so it is separate from the 40dp state layer that Checkbox and Switch render

That's unnecessarily specific and the information doesn't belong here.

The comment should only contain link to MD guidelines, not implementation specific notes.

[satya164]

minInteractiveSize is not a state. so it shouldn't be here

[satya164]

the comment is unnecessary. everything it says is self-evident

[satya164]

This could be simplified:

Suggested change

	{!disabled && (
	<View
	aria-hidden
	style={getTouchTargetStyle(hitSlop)}
	testID="touchable-ripple-touch-target"
	/>
	)}
	{!disabled && hitSlop != null && (
	<View
	aria-hidden
	style={
	typeof hitSlop === 'number' ? {
	position: 'absolute',
	top: -hitSlop,
	right: -hitSlop,
	bottom: -hitSlop,
	left: -hitSlop,
	} : {
	position: 'absolute',
	top: -(hitSlop.top ?? 0),
	right: -(hitSlop.right ?? 0),
	bottom: -(hitSlop.bottom ?? 0),
	left: -(hitSlop.left ?? 0),
	}
	}
	/>
	)}

[satya164]

remove hardcoded test id

[satya164]

what it used to is not relevant as a code comment

[satya164]

StyleSheet.flatten needs to be removed. add explicit border radius props if needed similar to Surface

[satya164]

Codex: We need to account for joined controls when adding this default. ToggleButton.Row renders 42x42 buttons with no gap, and on web the right button's expanded target covers the last 3px inside the left button's visible box. Browser hit testing selects the right button in that strip. We need component-specific slop for joined buttons so pressing inside one option doesn't activate its neighbor.

[k0ndee]

While working on ToggleButton.Row, I divided up hitSlop so adjacent buttons don't steal presses from each other on the shared edge, but that protection only applies to the horizontal Row layout.

When ToggleButton.Group is used bare, stacking buttons vertically (as shown in the "Group & enums" example), each button keeps its full, unshared hitSlop. Since there's no gap between them, pressing near the bottom edge of one button can activate the next one down instead. It is the same kind of overlap issue I fixed for Row, just not handled for vertical stacking.

Since Group is public API and documented to work without Row, this is reachable by anyone stacking toggle buttons vertically, not just in the example.

Options I see:

• Add a ToggleButton.Column — mirrors Row's existing logic, just for top/bottom instead of left/right
• Make ToggleButtonGroup orientation-aware so it handles this safely by default, without a new component

Which direction would you like for this PR, or should it be handled separately from the 48dp work?

[satya164]

Codex: We still accept corner radii through style, but the overlay and touchable now only get the radii from these props. With style={{ borderRadius: 0 }}, the disabled contained button's fill changes from square to circular. ToggleButton and ToggleButton.Row also still pass their corners through style, so their press effects get the wrong shape. We need one source for the shape and need to update the existing callers if we're moving the radii to explicit props.

[satya164]

Codex: We're calculating slop from the outer default size, but the touchable can be smaller. With the default outlined button, the 1px border leaves a 38x38 touchable, so 4px of slop only reaches 46x46. TextInput.Icon also passes a 24x24 style, which gives us a 32x32 target with this calculation. Both sizes were verified in the browser. We need to account for the rendered component dimensions and border when choosing the default slop.

[satya164]

Codex: These absolute offsets start inside the touchable's border, so we don't expand from its outer bounds. With a 40x40 touchable, borderWidth: 4, and hitSlop={2}, we get a 36x36 target overlay. A point 1px outside the visible button misses in the browser, though it should be within the requested slop. We need to account for the border when positioning the web target.

[satya164]

Codex: With ??, we replace an explicit hitSlop={null} with the computed default. TouchableRipple treats null as no slop, so we're losing the caller's override here. The same issue exists in both RadioButtons, Chip, and SegmentedButtonItem, while IconButton preserves null. We should only apply the default when hitSlop is undefined.

[satya164]

Codex: The Material Web reference doesn't support this exception. Its remove button renders a .touch element, and that element has 48px height. The 24x24 dimensions in _trailing-icon.scss are for the ripple and focus ring. Here we leave the close target unexpanded and give the strips above and below it to the body, so a tap near the close icon can activate the chip instead. We need vertical expansion for the close action and a matching division of the two targets.