Remove single range restriction for selection interface apis

[sambandaru]

Proposal

Remove the single-range restriction from the Selection API. Allow addRange() to accumulate disjoint ranges, rangeCount to return values > 1, and getRangeAt(index) to accept index > 0. The API was designed for multiple ranges; this reverses the 2011 restriction. Chromium is pursuing implementation.

Explainer: MicrosoftEdge/MSEdgeExplainers — Multi-Range Selection (PR)
Canonical issue: #41 (open since Jan 2015)
Chromium feature request: issues.chromium.org/504686717
Webkit open bug: webkit.org/b/186465

Spec changes required

1. Section 2 — Allow a collection of ranges instead of "a single range"
2. Section 3, addRange() Step 2 — Remove the abort; define accumulation/merge semantics
3. Section 3, rangeCount — Allow values > 1
4. Section 3, getRangeAt() — Allow index > 0

Prior vendor interest

• Google/Blink (TPAC 2017): @yoichio — "As Google Chrome, we are interested in supporting multiple range" (minutes)
• Microsoft (2015): Ben Peters — "Layout order is not possible without multi-selection" (public-webapps)
• Mozilla/Gecko: Ships multi-range for 20+ years. Stable, no web-compat issues.
• Flat Tree or Composed Tree #336 — Shadow DOM flat tree (TPAC 2024) acknowledges multi-range as a solution path
• Allow Selection to contain multiple ranges #115 — Developer request for table column selection, closed as dup of Support multi range selection #41

Request

Requesting discussion in the Web Editing WG to build consensus on removing this restriction.

[johanneswilm]

Call 2026-05-14:

Multi-range Selection Interoperability and Next Steps: Regarding the
implementation of multi-range selection, Olli Pettay highlighted that
Firefox's implementation is stable and they aim to avoid breaking
compatibility. The participants discussed the need for Apple and
WebKit's involvement, though no representatives were present.

[johanneswilm]

Call 2026-05-14:

Multi-range Selection Support (Issue 358): Sambamurthy Bandaru
introduced issue 358, which proposes removing the specification's
restriction that limits selection to a single range to allow for
multi-range selection, a feature Firefox has historically supported.
Johannes Wilm raised concerns regarding the potential impact on existing
JavaScript editors that assume single-range selection, but Sambamurthy
Bandaru noted an explainer has been added to address backward
compatibility. Dan Clark emphasized that this change would allow editors
to utilize platform capabilities instead of relying on complex
virtualization workarounds. The participants agreed to proceed with
caution, with the Chromium team planning to use counters and conduct
audits to assess the potential impact before implementation.