Re: [Selection] Should selection.getRangeAt return a clone or a reference?

On Fri, Jan 9, 2015 at 8:29 PM, Olivier Forget <teleclimber@gmail.com> wrote:
> On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor <ayg@aryeh.name> wrote:
>>
>>
>> > - It may never happen, but when multiple ranges are supported, are
>> > they bound to index?
>>
>> Everyone wants to kill this feature, so it's moot.
>
>
> Could you please point me to the discussion where this conclusion was
> reached? I searched the mailing list but I only found a few ambivalent
> threads, none indicating that "everyone" wants to kill this. Thanks.

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

The reason for all this is that while it makes wonderful theoretical
sense to support multiple ranges for a selection, and is necessary for
extremely sensible features like allowing a user to select columns of
a table, multi-range selections are nonexistent in practice.  A
selection that has multiple ranges in it is guaranteed to be
mistreated by author code, because no one actually tests their code on
multi-range selections.  More than that, Gecko code -- which is much
higher-quality than typical author code and much more likely to take
multiple ranges into account -- has tons of bugs with multi-range
selections and behaves nonsensically in all sorts of cases.  So in
practice, multi-range selections break everyone's code in the rare
cases where they actually occur.  In general, an API that has a
special case that will almost never occur is guaranteed to be used in
a way that will break the special case, and that's very poor API
design.

In theory, a redesigned selection API that allows for non-contiguous
selections *without* making them a special case would be great.
Perhaps a list of selected nodes/character ranges.  But multiple
ranges is not the way to do things.

Received on Saturday, 10 January 2015 16:31:01 UTC