[Selection] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)

[subject change]

Multiple selection is an important feature in the future. Table columns are important, but we also need to think about BIDI. Depending on who you talk to, BIDI should support selection in document order or layout order. Layout order is not possible without multi-selection.

I do not believe “everyone wants to kill it” is accurate. I agree with Olivier that it’s crucial to a full-featured editor. We don’t want to make sites implement this themselves.

From: Olivier Forget [mailto:teleclimber@gmail.com]
Sent: Monday, January 12, 2015 10:56 AM
To: Aryeh Gregor
Cc: Ryosuke Niwa; Koji Ishii; Webapps WG
Subject: Re: [Selection] Should selection.getRangeAt return a clone or a reference?

On Sat Jan 10 2015 at 8:30:34 AM Aryeh Gregor <ayg@aryeh.name<mailto:ayg@aryeh.name>> wrote:

I don't remember whether it was ever discussed on the mailing list in
depth.  The gist is that no one has ever implemented it except Gecko,
and I'm pretty sure no one else is interested in implementing it.  The
Selection interface was invented by Netscape to support multiple
ranges to begin with, but all the other UAs that reverse-engineered it
and/or implemented from the DOM Range specs deliberately made it
support only one range (in incompatible UA-specific ways, naturally).
Ehsan Akhgari, maintainer of the editor component for Gecko, is in
favor of removing (user-visible) support for multiple selection ranges
from Gecko, and last I heard no one objected in principle.  So the
consensus of implementers is to support only one range.  As far as I
know, the only reason Gecko still supports multiple ranges is because
no one has gotten around to removing them.  (Ehsan would know more
about that.)
OK I understand that. My concern here is that the general attitude is to ignore this problem and hope it somehow goes away. Unfortunately multiple range selections are not a "nice to have". All "real" editors (MS Word, Google Docs, etc..) support selecting multiple ranges, and it's very common for users to select a column of  a table. As the web platform makes great strides forward rich editing capabilities should also keep up.

If today we decide that multiple ranges is out then we are doing two things:
- promoting the "Selection is only ever one continuous range" fallacy to all web developers.
- delaying the arrival a decent spec that actually handles multiple ranges (or disjoint ranges or whatever it takes to do "real world" selections.)

I am worried this means it will be a very long time before the web platform supports developing editors with commonly accepted editing paradigms.