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> 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.