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.