Intent to Prototype: Multi-Range Selection

[Chromestatus]

Contact emails

sambamurt...@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Editing/multi-range-selection-explainer.md

Specification

https://github.com/w3c/selection-api/pull/359

Summary

Enables Selection API to hold and manipulate multiple disjoint ranges within a single document. Users can create discontinuous text selections via input devices or JavaScript APIs, and clipboard copy includes all selected ranges joined with newline delimiters.

Blink component

Blink>Editing>Selection

Web Feature ID

Missing feature

Motivation

Desktop applications like Microsoft Word and LibreOffice Writer support Ctrl+Click (Cmd+Click on macOS) to build non-contiguous selections. On the web, this interaction is blocked by spec-mandated single-range behavior in current Chromium, where Ctrl+Click replaces the existing selection. The gap is particularly noticeable for: Users switching between desktop editors and browsers who expect consistent Ctrl+Click behavior Power users copying non-adjacent table cells Web-based code editors that want native multi-cursor selection without custom overlays The Selection API exposes a Selection object with methods like addRange(), removeRange(), getRangeAt(index), and the rangeCount attribute, all originally designed for collections of disjoint Range objects. In 2011, the spec was narrowed to single-range semantics: addRange() is ignored when a range already exists, and rangeCount is constrained to 0 or 1. Chromium follows this restriction today, while Firefox has long supported multi-range behavior. Issue https://github.com/w3c/selection-api/issues/358 had been discussed in the W3C Web Editing Working Group to restore multi-range semantics and align implementations across browsers with the API’s original design intent.

Initial public proposal

https://github.com/WICG/proposals/issues/291

Search tags

range, multi-range, selection

Goals for experimentation

None

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/504686717

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5095241565732864?gate=5095962528841728

This intent message was generated by Chrome Platform Status.

[Emre TEKE]

Hello,

I am writing this as an independent Chromium contributor.

I have reviewed the specification and noticed that it primarily focuses on mouse events. While the documentation mentions accessibility in passing, I could not find specific examples regarding how a screen reader user would interact with multi-range selection.

I would appreciate it if there is any relevant documentation or a specific prototype that demonstrates this behavior. 

Although I frequently use VS Code and other cited examples, I am not familiar with how multi-range selection is handled via screen readers.

I apologize if this inquiry is outside the typical scope of this group; however, this remained unclear to me after reading the spec and I felt this would be the best place to ask for clarification.

17 Haziran 2026 Çarşamba tarihinde saat 07:07:28 UTC+3 itibarıyla Chromestatus şunları yazdı: