Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#474 0 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
javascript, react-native
Área
frontend, mobile

Línea de trabajo

Comienza con el punto de entrada createStrictDOMTextComponent y compáralo con createStrictDOMTextInputComponent; después, reproduce el ejemplo mínimo de Expo/iOS del issue. Rastrea cómo los elementos de texto HTML nativos se asignan a componentes de React Native y evalúa la estructura opt-in propuesta para selectable. El resultado debería proporcionar una selección de texto nativa parcial en iOS sin cambiar el comportamiento predeterminado ni el de la web.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
JavaScript
Estrellas
3.6k
Forks
208
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de react/react-strict-dom

Todos los issues de react/react-strict-dom

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.