Just let me select text

Intentional irony of the article

  • Many notice the post itself disables text selection via CSS, unlike the rest of the blog.
  • Consensus: it’s deliberate “performance art” to demonstrate how annoying this pattern is, not an accident.
  • Some readers find it funny and effective; others find it so irritating they stop reading.

User pain: translation, copying, accessibility

  • Common use-cases blocked by non-selectable text:
    • Translating bios, reviews, UI labels, and buttons (especially on dating apps, social apps, and foreign-language sites).
    • Copying addresses, order numbers, OTP codes, ticket IDs, tracking numbers, and error messages.
    • Sharing exact labels or instructions (“click ‘My Account’ then…”) or reusing content (e.g., interview answers, technical strings).
  • Non-selectable text especially hurts users dealing with non-Latin scripts; typing characters manually is often unrealistic.
  • Some people habitually highlight text while reading as a focusing aid; disabled selection directly harms their reading experience.

Platform workarounds & OCR tools

  • Widespread reliance on OCR as a workaround:
    • Android: app switcher “Select” mode, Google Assistant, Lens, and “Circle to Search” can OCR any screen; highly praised but device- and vendor-fragmented.
    • iOS/macOS: screenshot-based Live Text/Preview OCR and system translation; many now routinely screenshot apps just to copy text.
    • Windows: PowerToys “Text Extractor”; Linux/macOS users script maim+tesseract or similar.
  • These tools work even in hostile apps, unless screenshots are blocked (common in banking/payment and some messaging apps).

Why developers disable selection

  • Reasons given or inferred:
    • Prevent janky behavior when dragging tabs, buttons, draggable UI elements, or tiles.
    • Follow native app norms where labels/buttons are traditionally non-selectable.
    • Anti-copy / “content protection” or keeping users from easily taking data to other apps (dating apps, SaaS, lyrics, policy generators).
    • Attempted friction against doxxing, spam, or profile plagiarism.
  • Many commenters argue these motivations don’t actually prevent abuse but do harm legitimate users.

Debate over clickable UI elements

  • One camp: any visible text (including tab headers, buttons, nav labels) should be selectable for translation, copying, and accessibility.
  • Opposing camp: for things like draggable tabs and buttons, selection interferes with keyboard and mouse navigation; better UX to disable selection there.
  • Several argue the web’s default behavior (everything selectable unless truly necessary) is a good baseline; extra CSS/JS to block selection is almost always user-hostile.

Web vs native apps; tooling and countermeasures

  • Web pages remain easier to “liberate”: users can disable CSS, use reader mode, DevTools, uBlock filters, bookmarklets, or extensions that force user-select:auto.
  • Native and cross-platform toolkits (iOS Text/Label, Android TextView, React Native, Flutter, Electron apps) often default to non-selectable text, making fixes harder.
  • Broader frustration: copy/paste breakage, right-click hijacking, target=_blank everywhere, and whole UIs rendered as images are cited as part of a general UX backslide or “enshittification.”