First-class (partial) text selection support on mobile (iOS) for `<html.p />`, `<html.h1 />`, `<html.span />`, et al

Bắt đầu với entry point createStrictDOMTextComponent và so sánh nó với createStrictDOMTextInputComponent, sau đó tái hiện ví dụ Expo/iOS tối thiểu từ issue. Theo dõi cách các phần tử văn bản HTML native được ánh xạ tới các component React Native và đánh giá cấu trúc opt-in được đề xuất cho selectable. Kết quả cần cung cấp khả năng chọn văn bản native một phần trên iOS mà không thay đổi hành vi mặc định hoặc hành vi trên web.

Describe the feature request

On iOS (only mobile platform I've tested so far), let text-bearing html.* elements:

• html.p
• html.h1 ... html.h6
• html.li
• html.span
• html.code
• et al

...participate in the native partial-text-selection affordance:

• drag to extend a range
• selection handles
• magnifier
• ...and the system edit menu; i.e.:
  • Copy
  • Look Up
  • Translate
  • Share
  • Speak
  • Writing Tools

Same behaviour React Native for (Desktop) macOS already provides via react-native-macos's NSTextView (and that browsers provide on web).

iOS is the outlier.
Android: yet to be tested. (OpenHarmony, likely entirely out of scope).

Current behaviour

Setting userSelect: 'text' on a text-bearing html.* element on iOS surfaces the iOS edit menu on long-press, but only with Copy. There is no selection range: the menu opens directly, dragging does nothing, no magnifier, no handles. Tapping Copy copies the whole element's text rather than a chosen range.

Minimal reproduction (Expo SDK 55 + react-strict-dom@0.0.55, iOS 16+):

import { html, css } from 'react-strict-dom';

const styles = css.create({
  p: { fontSize: 16, lineHeight: 1.45, userSelect: 'text' },
});

export default function Demo() {
  return (
    <html.p style={styles.p}>
      Long-press this paragraph on iOS. The system edit menu opens
      immediately with only `Copy`. No selection handles, no
      drag-to-extend, no magnifier. The same `html.p` on macOS
      supports full partial selection.
    </html.p>
  );
}

Why it matters

The asymmetry breaks consistent UX across the platforms RSD targets:

Platform	Partial selection	System edit menu
Web	✅ browser default	✅ browser default
macOS (react-native-macos)	✅ NSTextView default	✅ AppKit default
iOS (react-native)	❌	Copy only
Android (react-native)	❌	([likely] out of scope here)

For any reader-oriented surface (articles, chat messages, notes, markdown viewers, quoted replies) partial selection is table stakes. Users who experience macOS and iOS in the same app are particularly badly served by the gap.

Root cause

html.p / html.h1 ... html.h6 / html.li / html.span / html.code all map to react-native's Text on native (createStrictDOMTextComponent → Text). React Native's iOS Text is RCTParagraphComponentView (Fabric) / RCTTextView (legacy): a custom UIView that draws via NSLayoutManager. It doesn't implement UITextInteraction, so iOS has nothing to attach selection handles to.

The well-known RN-iOS workaround for partial-text selection is <TextInput editable={false} multiline selectable />, backed by UITextView and inheriting full selection + native edit menu. RSD already maps html.input and html.textarea to TextInput via createStrictDOMTextInputComponent: the primitive is right there; it just isn't what static text elements compile to.

Proposed shapes (sketches, in increasing invasiveness)

1. New selectable HTML prop, opt-in: RSD adds a selectable boolean prop to text elements; when true on iOS, the underlying renderer wraps the content in a read-only TextInput. Default false; web semantics unchanged.

   <html.p selectable>…</html.p>
   

2. Render-mode escape hatch: a new prop or variant that lets a consumer opt into TextInput-backed rendering for paragraphs / headings they want fully selectable. More general than a single boolean

3. Map userSelect: 'text' (or other) to TextInput-readonly on iOS automatically: most magical, most spooky-action-at-a-distance; possibly breaks consumers relying on Text-specific layout behaviour that TextInput-readonly approximates rather than matches

"1" seems like the cleanest first cut: opt-in, doesn't change defaults, matches the platform reality that "selectable static text on iOS" is a distinct rendering choice rather than a free property of Text.

Workarounds (naive assumptions...)

• <TextInput editable={false} multiline selectable /> used directly (canonical RN-iOS pattern, but bypasses RSD's semantic mapping)
• react-native-selectable-text: community library wrapping the above
• Conditional renderers that swap RSD primitives for RN's TextInput on iOS: works but pushes platform-divergence into consumer code

All of these work, but each lives outside RSD's surface. The gap is a consistent, RSD-supported way to mark static text as selectable that handles the platform divergence so consumers don't have to.

Related / "Prior Art"

• React Native issue #23147 (closed): original observation that selection ranges aren't exposed on Text; the RN team's answer was effectively "use TextInput read-only," which is the right RSD-side answer if you accept that rendering choice
• RSD's recent input-side setSelectionRange / selectionStart / selectionEnd polyfill work (commit 65e439b, Dec 2025) shows selection is on the roadmap on the input side; static-text selection is the natural companion

(Likely) Out of scope

• Editor/ cursor/keyboard navigation (these need editable-true paths and are larger)
• Android partial selection (related, but RN-Android has its own constraints; deserves a separate issue)
• Selection-event callbacks (onSelectionChange on static text): useful, but layerable on top of basic selection support