Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#474 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
javascript, react-native
Ambito
frontend, mobile

Direzione di ricerca

Inizia dal punto di ingresso createStrictDOMTextComponent e confrontalo con createStrictDOMTextInputComponent, quindi riproduci l’esempio minimo Expo/iOS dell’issue. Traccia il modo in cui gli elementi di testo HTML nativi vengono mappati ai componenti React Native e valuta la struttura opt-in proposta per selectable. Il risultato dovrebbe fornire una selezione del testo nativa iOS parziale senza modificare il comportamento predefinito o quello web.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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 + [email protected], 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
Lingua principale
JavaScript
Stelle
3.6k
Fork
206
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di react/react-strict-dom

Tutte le issue di react/react-strict-dom

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.